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MCERC is a database design and implementation to support the survey 
instruments for the USMC Exit and Retention Censuses, which are administered over the 
Internet. The Retention Census is a longitudinal survey administered annually to all 
Marines. A review of commercially available survey software revealed a lack of support 
for longitudinal surveys. A semantic object model for survey instruments is developed that 
relates them to the response data they collect. The resultant database schema facilitates 
version management of survey instruments over their lifecycle. The design supports the 
longitudinal aspect of the USMC Censuses by allowing the tracking of the instruments and 
response data over time. A relational model of the database design is prepared and 
implemented in Access™. A user interface is designed using Visual Basic, which 
integrates Cognos Powerplay™ into the system for analysis of the data. The interface 
includes the capability to convert raw data into a matrix for analysis. Issues of database 
administration are discussed as they relate to scaling the system from a stand-alone to a 
multiple-user environment. 
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I. INTRODUCTION 



Retention of "corporate knowledge" is vital to any large organization. The United 
States Marine Corps (USMC), as well as all other military services in the United States, 
constantly faces the loss of critical skills and leadership as top quality Marines choose to 
leave the service for a variety of reasons. Policymakers must decide what actions are 
possible and necessary to keep well-trained Marines motivated to stay in the service. 
Toward this end, the USMC has initiated the USMC Exit and Retention Censuses to be 
implemented beginning in Fiscal Year 1999 and continuing indefinitely on an annual basis. 
The initiative takes advantage of contemporary technology, by placing the survey 
instrument on the Internet as the vehicle for data collection. This thesis produces a 
database design and implementation to facilitate understanding, analysis, and 
administration of the collected data as well as management of the census questionnaires 
throughout the lifecycle of the censuses. 

A. BACKGROUND 

The USMC Exit and Retention Censuses (or surveys) will ask over 200 questions 
of as many Marines as possible every year. The intention as stated by the program 
sponsor, Manpower and Reserve Affairs (M&RA), Headquarters USMC (HQMC), is to 
have 100 percent participation, less general officers, officer candidates, and recruits. 
Marines exiting the service must complete the Exit Census prior to being fully discharged. 
All others are to complete the Retention Census on an annual basis. Both are conducted 
via the Marine OnLine (MOL) website on the World Wide Web. The effort is intended to 
harness contemporary information technology to make the surveys easily accessible and 
thorough. The result will be a very large repository of survey information, with many 
thousands of Marines responding to many questions every year. For the Retention 
Survey, the database will have response data for many of the same Marines across multiple 
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years. Therefore, one of the results of the Retention Census will be a longitudinal study, 
where the same individuals will be polled for their responses across numerous timeframes. 

Given the vast amounts of data that will be collected over the years, a wealth of 
potential analyses can be drawn from the data. However, there is a challenge inherent to a 
longitudinal study initiative in that the survey instrument itself will very likely be refined 
many times during the lifecycle of the study. To ensure the data is consistently 
understandable, these refinements to the survey instrument must be assiduously tracked. 
While it is important to field the best possible survey instrument at the beginning of the 
study, it is also essential to be able to modify existing questions on the instrument and add 
new questions as well as analyze the response data relative to these survey instrument 
modifications. Ultimately, the data collected over the years will be used for hypothesis 
testing in order to predict the outcome of policy options. Preliminary analysis of the data 
will be accomplished using software for crosstabulations to display and examine 
distributions. As data is collected over the long term, erratic data for certain variables may 
be explained by the questions asked on the survey instrument at the time. [Cooper and 
Emory] Thus, the capability to track changes to the survey instrument is an essential 
feature of any longitudinal study. 

At some future state of the Exit and Retention Census initiative, the data collected 
in prior years may potentially be rendered unusable because the changes to the survey 
instrument become impossible to track. This thesis provides a conceptual data schema 
that results in the capability to manage changes to the survey instrument to avoid this 
situation. In addition to the data schema, a system is implemented which demonstrates the 
capabilities for managing the survey instrument and analyzing the collected data for the 
USMC Exit and Retention Censuses. 

B. PURPOSE 

The purpose of this study is to design an effective database schema to support a 
longitudinal survey which will accommodate inquiries over time as the same respondents 
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answer the survey from year to year, and which will itself change over the years. The 
resulting schema can be used to support the administration of the USMC surveys. In 
addition an interface to the database is provided to enable the extraction of subsets of the 
database for analysis in support of the manpower decisionmaking process. To implement 
the system, meaningful user interface requirements for the survey developer and analyst 
are identified and analyzed in relation to the database schema. 

To motivate identification of the database requirements, an overview of existing, 
Web-based survey software packages is conducted. This will illuminate what features and 
functionality are desirable for our database system. In particular, the time semantics, or 
version management, dimension of this database is critical to a successful implementation. 

Extensions of the basic concepts developed by this study are discussed to provide 
input for improving and maintaining the longitudinal survey system. Ultimately, the goal 
of the system is to build a uniform environment for survey development, administration, 
and analysis. Recommendations are included for enhancing the system developed in this 
thesis. 

C. SCOPE AND METHODOLOGY 

The scope of the thesis includes the following: 

1. An overview of survey software packages available with integrated analysis 
capabilities. Additionally, statistical analysis software available for analyzing 
the data regardless of the software for administration of the survey instrument 
is reviewed. 

2. The development of a data model/schema for the capture of data from the 
survey and for the capture and tracking of changes to the surveys and 
questions. This supports the longitudinal aspect of the survey. 

3. Implementation of the database in Microsoft Access, including the user 
interface between Access and an analytical software package. 
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4. Design and development of a user interface in Visual Basic to enable the 
integration of the database with analytical software packages. This provides 
the capability to obtain certain pre-formatted reports and data extracts. 

The following methodology is used to conduct this research: 

1. Conduct a literature and World Wide Web search for information on analytical 
software for surveys. Analyze the relative capabilities and functionality of the 
programs found. 

2. Develop a conceptual data model for the longitudinal surveys using SALSA™, 
which could theoretically be applied to any longitudinal study. Analyze and 
determine the necessary entities and relationships to facilitate the longitudinal 
nature of the study. 

3. Convert the conceptual model to a relational database model and implement 
the model in Microsoft Access. 

4. Design interface forms in Access as the user interface to the survey instrument 
database. 

5. Design preformatted standard reports and data extracts. 

6. Develop a user interface in Visual Basic to allow the system administrator to 
manage the survey instrument, and manipulate and analyze data through a 
single system interface. The interface facilitates the use of Cognos 
Powerplay™ for viewing the data. 

7. Populate the database with the first version of the Exit and Retention survey 
instruments, and develop procedures for maintaining the instruments for future 
versions. 

8. Implement the database by downloading a subset of respondent information 
entered by Marines via the World Wide Web. Produce reports and various 
data extracts using the data. 

9. Document the process of design and development, conclusions, lessons 
learned, and recommendations for follow-on study. 

10. Prepare a user's manual for the managers, and a procedures guide for the 
project officers who will be maintaining the system throughout its lifetime. 



4 



D. THESIS STRUCTURE 



This introductory chapter has provided the background, scope and methodology 
for the thesis. Chapter II is a discussion of the various software components needed for 
the thesis and an overview of commercial software available. In Chapter III, the problem 
areas of the thesis are discussed and requirements of the system are specified. Chapter IV 
presents the conceptual design for building the database, including the data models, 
database schema; constraints, and database administration. Chapter V describes building 
the User Interface, including the development of process models, design and creation of 
menus, screens and reports, generation of application code, and development of a user's 
manual. In addition to conclusions, recommendations for future enhancements are 
included in Chapter VI. 
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II. SURVEY SOFTWARE OVERVIEW 



The USMC Exit and Retention Census initiative, with its web-based survey 
instrument, is intended to leverage contemporary technology to fulfill its objectives. It is 
important to understand the basic processes and components inherent to a complete 
survey system, and to find appropriate technology to support those processes. Toward 
this goal, we start with a review of web-based survey systems, keeping in mind the 
particular requirements to support the longitudinal study being undertaken by the USMC. 
This chapter provides a conceptual overview of the system and reviews several software 
packages, documenting their relative capabilities. 

A. WEB-BASED SURVEY SYSTEMS 

Software to support the USMC's web-based surveys requires features above and 
beyond basic database functionality which provides permanent response storage 
capabilities as well as web-authoring tools for the survey instrument. The first component 
is the application that contains the actual survey questionnaire and facilitates its 
deployment to the web. This software assists the survey administrator in survey 
instrument development and maintenance. It may include a web-authoring capability to 
facilitate placing the instrument on the web in which case the web-based instrument then 
facilitates the transmission of responses into a data file for permanent storage. Once 
response data is collected, another software package (if not an integrated part of the 
survey software) facilitates analysis of selected subsets of the data. Software for the 
development of a user interface between the database and the data analysis program will 
also be necessary unless the components are already integrated. 

Figure 1 shows a schematic of a web-based survey system with the basic hardware 
components and their interaction with applications, data, and software components. 
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Figure 1. System Schematic of Longitudinal Web-Based Survey 

The Surveyor's goal is to have information about Respondents. The large number 
of Respondents requires that a robust mechanism be in place for them to deliver that 
information, rather than a direct link between the Surveyor and the Respondents. 
Therefore the survey instrument is delivered to the Respondents as an HTML survey from 
a web server. Respondents then enter data which the web server collects and sends to the 
Permanent Database. The Respondents only interact with the web server in their role of 
providing the data to the system. 

The Surveyor's role as depicted in Figure 1 is clearly more involved than the 
Respondent. The Surveyor must develop and deploy the Survey instrument on the Web 
Server. Prior to placing it on the web, it must be designed, documented and stored for 
future reference using the Survey Application. Figure 1 shows the Surveyor employing a 
User Interface to place information about surveys in the Survey Application. The survey 
instrument is then permanently maintained in the Survey Application. The Surveyor also 
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sends requests via the user interface to the Analysis Software for analysis of response data 
and to the Survey Application for the survey instruments and related reports. When the 
Surveyor sends request to the Analysis Software, the response data is passed from the 
Permanent Database to the Analysis Software either directly or via the User Interface. 

Given this general overview of the system components, the software required to 
support the USMC Surveys must include: 

1. Survey software to develop Survey Instruments and maintain them in a 
database for the lifecycle of the USMC Surveys; 

2. Analysis software to provide analytical capabilities for research on response 
data collected; 

3. Graphical User Interface (GUI) software such as Visual Basic to provide an 
integrated system environment for the user. 

The still growing popularity of the Internet has generated a vast supply of flexible 
web-based development tools. These tools are evolving rapidly, with a wide variance in 
the approaches software development companies are taking. As a result, there are 
numerous tools of varying quality that can be used for the development of an HTML 
survey instrument. There is a number of software development companies with 
specialized survey development packages. Since these tools are designed specifically for 
survey development, most of them have an internal analysis capability, as well as the 
ability to format the data for transfer to a robust statistical analysis tool. A powerful 
alternative to purchasing a specialized survey development tool is to use web-authoring 
software for survey creation, and to choose a robust statistical analysis package to 
examine the results. Increased availability of web-authoring software fulfills this need. 
Accordingly, various web-authoring tools for surveys and their associated capabilities and 
limitations are examined in the next section. In the subsequent section, statistical analysis 
software capable of providing a broad range of statistics on complex data subsets is 
examined. A survey of these two components of the survey system will give the 
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contemporary surveyor a good sense of the current state of software for collecting and 
understanding large volumes of data. 

Software to support the other component of the longitudinal survey system, the 
GUI interface, is more widely understood and will not be reviewed here. The software for 
developing the GUI interface component should be a flexible programming language such 
as Visual Basic. 

B. SURVEY SOFTWARE. 

There are numerous quality development tools for the creation of web-based 
surveys. Many come with their own data administration modules, as well as analysis 
packages. For the USMC Retention and Exit Survey, as with most web-based surveys, 
the survey software chosen requires certain capabilities. It must: 

1 . allow lengthy surveys (of at least 280 questions); 

2. allow many respondents; 

3. allow branching in the survey so that respondents need only respond to 
appropriate questions; 

4. automatically populate the database; 

5. provide security of respondent’s private information; 

6. provide entry validation; 

7. provide a user friendly interface for administrators and the respondents; 

8. allow a wide range of item and response types. 

Because this is a longitudinal survey system, the responses will be stored in a 
permanent database external to the web survey package, so there is no requirement for 
this component to have an analysis or data management capability. However, these 



10 



capabilities are imperative for the system as a whole, so the analytical and data 
management components, if any, of packages will be considered. 

This examination of web survey development packages concentrates on those 
showing promise to support extensive, long-term surveys. There are numerous packages 
available which are designed to support web surveys on a smaller scale and for one-time 
surveys, such as specific marketing studies. This examination should not be considered as 
a comprehensive list, but an evaluation of only a few of the means of getting a survey 
instrument on the web. 

The survey development tools in Table 1 can be used for implementing a survey on 
the web. Most include analysis capabilities in addition to merely deploying a survey 
instrument. Although not a tailored survey software application, Lotus Domino is 
included as a development tool that can be used to design a proprietary survey application. 



Capabilities 


Cost 


Does 

Large 

Surveys 


Longitudina 
1 Studies 


Works 

With 

Other 

Software 


Entry 

Validation 


Analysis 

Capability 


Security 


Products 


Survey Select 
Saja Software, 
Inc. 


$595 to 
$1285 


Yes 


No 


Yes 


Yes 


Limited 


Yes 


Survey Solutions 
Perseus 
Development 
Corp. 


$179 


Yes 


No 


Yes 


Yes 


Limited 

statistics 


Unknown 


Domino 

Lotus 

Development 

Corp. 


$495 


Yes 


N/A 


Yes 


Yes 


N/A 


Yes 


Inquisite 

Catapult Systems 
Corp. 


Call for 
price 


Yes 


No 


Yes 


Yes 


Limited 


Unknown 


Surveys with 
Confidence 
SPSS, Inc. 


$999 


Yes 


No 


Yes 


Yes 


Complete 


Unknown 


SurveyTracker 
National 
Computer 
Systems, Inc. 


Call for 
price 


Yes 


No 


unknown 


Yes 


Complete 


Unknown 



Table 1. Summary of Survey Software Packages/Options Reviewed 
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In order to support large surveys, an application must support branching, large 
numbers of respondents, and many questions. To support longitudinal surveys, a package 
must also have the capability to manage versions of surveys and questions. 

The survey software should allow importing and exporting in commonly used 
formats to be compatible with other applications that might be used in conjunction with it. 
For instance the survey instruments might be desired for publication to the web in HTML 
or a report might be desired from it for downloading in a particular desktop administrative 
tool. Additionally, the data collected should easily be made available for analysis in a 
program of the user's choice. Some survey software comes with built-in analysis tools, but 
the capabilities are usually limited. 

For Entry Validation, the software should provide a way to define validation rules 
when respondents provide answers. This capability includes the support for multiple data 
types, and helps ensure that the data being received is indeed the data desired for analysis. 
Entry validation also provides data integrity, since data of undesired format is prevented 
from polluting the database. 

Security provides control over data access, another aspect of data integrity. A 
good survey software package should provide some level of security for the database, as 
well as the response data. It should also ensure that any private information of 
respondents is protected. From the perspective of respondents, a security feature that 
maintains their anonymity also encourages them to provide candid responses. From a 
database administration perspective, the feature is necessary to protect confidential 
information. 

Some survey software packages have variable price ranges, depending on the 
desired functionality. Additional modules may be needed to give the survey software a 
web-based, e-mail or network capability. 

No survey software reviewed mentioned the administration of longitudinal surveys. 
Those that have the complete analysis capabilities could certainly handle the analysis of 
longitudinal data, but the problem of tracking a survey instrument over time is not 
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explicitly considered by any of them. The impetus for these commercially available survey 
tools is largely marketing and customer satisfaction surveys. Longitudinal studies require 
a long-term commitment and dedicated administrative overhead to manage the overall 
process. The lack of a short-term payoff makes this type of study unattractive to the 
business world, which constitutes most of the market for the software vendors. 

Longitudinal studies are more in the realm of government, research and academic 
organizations. As such, they are centralized and serve the broad purposes of a large 
community with long term goals. Software applications designed to support such an 
effort would be proprietary by nature. This observation gives insight into the apparent 
lack of support for longitudinal surveys in conjunction with commercially available survey 
software. 

The USMC Survey Instrument was designed for the web using Lotus 
Development Corporation's Domino software. The first iterations of both the Exit and 
Retention Censuses were designed and implemented without a database schema to support 
tracking multiple survey instruments over time. This thesis provides a design and 
implementation of a Microsoft Access relational database to manage a longitudinal survey. 
Because the Survey Instrument has already been built and placed on the Internet, the 
requirement for this study is to store the details of the Survey Instrument in an appropriate 
database application. The main goal of the system is to provide survey instrument 
lifecycle management for both longitudinal and static surveys. Links to analytical 
capabilities will be provided in two ways: a text file can be generated which can 

subsequently be imported into statistical analysis software packages such as SAS™ or 
SPSS™, and a direct connection will be provided to the Cognos Powerplay™ tool which 
can do multidimensional crosstabs displays and reports. 

Now that we understand the components that should be in a generic, longitudinal 
survey system, we can apply this insight to the USMC Surveys to generate specific 
requirements as discussed in the next chapter. 
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III. PROBLEM BACKGROUND AND REQUIREMENTS SPECIFICATION 



The Marine Corps Exit and Retention Censuses are the impetus for the 
development of a data model and schema that reflects their particular requirements. The 
Marine Corps' initiative is to conduct two surveys primarily for the purpose of statistical 
analysis. All Marines who are exiting active duty will be required to take the Exit survey. 
On an annual basis, all Marines will be required to take the Retention survey. An overall 
objective is to capture data about four classes of people: those who say they are leaving 
and leave; those who say they are leaving and stay; those who say they are staying and 
stay; and those who say they are staying and leave. General officers, officer candidates, 
and recruits will not be required to take the surveys. [CMC, 1999] While there are 
questions asked on the Exit survey that are only appropriate for a Marine who is leaving 
the service, and questions on the Retention that are only asked of Marines staying in, there 
are also many questions common to both surveys. It is necessary to analyze the data 
elements of these surveys that will be captured in the database in order to understand these 
requirements. For clarity and brevity, we adopt the unofficial acronym MCERC (Marine 
Corps Exit and Retention Censuses) for the system being developed to support the USMC 
surveys in this thesis. 

A. USMC SURVEY REQUIREMENTS 

The survey instrument provides the necessary information to gain a basic 
understanding of the survey system requirements. By studying the questions and response 
alternatives, the type of data that will be held in the database can be determined. The data 
collected as well as the questions themselves must be kept in the database in a logical 
schema so the data can be related back to the questions asked. Information about the 
survey instruments and each question on them should be maintained for the survey 
management aspect of the system. This information is typically referred to as a codebook 
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for the survey. Another aspect is that of data analysis, for which response information 
must be kept, including data about the responses and the respondents themselves. 

A representative sample of questions from the Exit and Retention surveys is given 
in Figure 2. Both surveys are lengthy, with a broad spectrum of questions. The Exit 
survey has over 150 questions, and the Retention survey has over 250 questions. Many 
questions are repeated between the two surveys. The questions from the Retention survey 
can be found in Appendix A. 



Spoucareer 


To what extent have your spouse's career opportunities been limited by frequency 7 of relocation? 


1 . 


Not at all 


2. 


Somewhat 


3. 


A great deal 


spouloca 


To what extent have your spouse's career opportunities been limited by frequency of relocation? 


1 . 


Not at all 


2. 


Somewhat 


3. 


A great deal 


daycare How satisfied are yu with the availability of daycare in your area? 


4. 


Very satisfied 


3. 


Somewhat satisfied 


2. 


Somewhat dissatisfied 


1 . 


Veiv dissatisfied 


0 . 


n/a 


marital What is your current marital status? 


1 . 


Single and never married 


2. 


Single and divorced 


3. 


Legally separated 


4. 


Married (first marriage) 


5. 


Married (previously divorced or widowed) 


6 . 


Widowed 


milhousing 


Do you live in military housing? 


1 . 


Yes 


2. 


No 


trainready 


I have received the training needed to make my contribution to unit readiness. 


4. 


Strongly agree 


3. 


Somewhat agree 


2. 


Somewhat disagree 


1 . 


Strongly disagree 



Figure 2. Questions and Choice Alternatives for USMC Surveys 
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Although there are various formats for survey questions, the concept is 
straightforward. A survey question is presented and a respondent provides a response to 
it. MCERC must be flexible enough to accommodate different formats for responses. 
Since there will be different types of data based on the responses, it must also be rigid 
enough to maintain integrity of responses in spite of the variance in their formats. 

The requirements for the basic survey system can be divided into two main 
categories: providing a relational database structure, and making the data available for 
analysis and reports. 

Because the USMC intends this to be a longitudinal study, the factor of time must 
be accommodated in the schema. Where many surveys are conducted only to gather a 
one-time data sample, the USMC surveys will presumably be conducted over many years. 
The Exit survey will be a requirement for every Marine to take before leaving active duty 
service. With the Retention survey, the same respondents may be responding multiple 
times, and the intention is that there be mandatory annual participation. Thus the 
Retention survey is truly longitudinal in that the same respondents will be providing 
responses to the same questions as well as new and revised questions over time. 
Therefore, there is a requirement to structure the data in a manner that captures this 
longitudinal aspect. 

The intention to field the surveys for many years dictates that inevitable changes to 
the survey instrument must also be accommodated. The high likelihood that questions will 
be added, subtracted, or modified creates the need to track these types of changes as they 
occur over the lifetime of the survey system. Analysts of the data need to know when 
their time-series data is based on more than one version of a question. 

Requirements to provide survey management as well as data analysis have been 
identified. These, combined with the requirement to accommodate them within a single 
system, drive the design of a user interface. This interface should allow the user to easily 
enter questions into the MCERC database and associate them with appropriate survey 
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versions. It should allow for modification of existing questions, and addition of questions 
without compromising the data collected prior to the change. The interface will also allow 
users to generate output files that can be accessed by statistical analysis software which 
can manipulate and analyze the responses. 

B. ANALYSIS REQUIREMENTS 

There are many possibilities for analysis of the data that will result from these 
surveys. Of primary interest is how variance in responses fluctuates among different 
demographic factors. For instance, there may be interest in how responses to questions 
relating to leadership style vary by Military Occupation Specialty (MOS). Responses to 
certain questions by female Marines may be compared to the responses of males. Certain 
communities within the Marine Corps reflect a high investment and are difficult to retain. 
Any analysis that may give insight into these communities may help shape policy to retain 
their critical skills. As an example, the aviation community may respond quite differently 
to questions about military benefits than other communities. These kinds of analyses can 
potentially provide the type of insight decision-makers need to craft policy. For MCERC, 
the data analysis capability must give views of the data that show the relative numbers of 
responses against desired variables. 

For the USMC Surveys, the reporting and analytical software in use by the survey 
sponsor, Manpower and Reserve Affairs (M&RA), Headquarters, U. S. Marine Corps 
(HQMC), is PowerPlay™ by Cognos, Inc. Powerplay™ provides the user with 
crosstabulations capability. It comes with a component, Transformer™, which allows 
data modeling for multidimensional analysis. Powerplay™ is a leading Online Analytical 
Processing (OLAP) tool with extensive drill-down, slice and dice capability. MCERC 
must provide a way via the user interface for the analysts to access the capabilities of 
PowerPlay™. 

A summary of requirements for the MCERC system requirements is given in 
Table 2. 
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Summary of Requirements 


Category 


Requirement 


Survey Management 


Database schema for management of Surveys and Questions 




Must accommodate changes in survey instrument (questions and surveys) 


Data Analysis 


Response data must be related to Surveys and Questions in the schema. 




Data schema must support longitudinal analysis of responses 




Interface must integrate survey database and PowerPlay™ analysis software 




Must be able to generate Survey Codebooks 



Table 2. Summary of Requirements for MCERC to Support the USMC Surveys 

With these requirements specified, the data model for MCERC can be developed 
and implemented, then integrated with the analysis software via a user interface to provide 
all required capabilities of the system. 
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IV. BUILDING THE DATABASE 



One of the key milestones for the implementation of the longitudinal survey system 
is the development of an appropriate data model and corresponding database schema. The 
model must correctly portray the various entities that exist in the survey application as 
well as the relationships between them. Similarly, the database schema must implement 
these entities and relationships in a physical database that serves as the engine of the 
overall system. Data models and a database schema for MCERC are developed with 
system requirements in mind as the basis for deeper analysis. 

A. DEVELOPING THE CONCEPTUAL DATA MODEL 

A successful database implementation should be preceded by the development of 
thoroughly analyzed data models. To obtain an appropriate data model for a system, the 
methodology used should take the requirements of the system as the basis for developing 
and documenting the model. Two methodologies for accomplishing this are the Entity- 
Relationship (E-R) Model and the Semantic Object Model (SOM). The E-R approach 
identifies each entity and all of its associated relationships with other entities. The SOM 
approach also identifies entities (called semantic objects) as well as their attributes, 
although, unlike the E-R approach, SOM represents relationships between objects in a less 
explicit manner. Objects are embedded within other objects to reflect a relationship. 
SOM also gives all the attributes and associates them directly with the objects. The nature 
of the relationships between objects and with attributes can also be described in SOM by 
showing cardinalities. The SOM approach is used in this thesis to derive a data model for 
MCERC. 

1. Primary Objects 

The first issue is to determine what the actual objects should be in the survey 
system. David M. Kroenke defines an object as “a named collection of attributes that 
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sufficiently describes a distinct entity.” [Kroenke, 1995] Based on an analysis of the 
system requirements, the following objects have been identified as integral to the system: 
Surveys, Questions, Respondents, and Responses. 

The Semantic Objects relating to these four objects are presented in Figure 3. As 
can be seen, a semantic object has its attributes associated directly with it by simply listing 
them within the object. Key attributes (identifying attributes) are designated with asterisks 
in the figure, using two asterisks for unique keys and one for non-unique keys. To 
establish a relationship between objects, the objects are embedded in each other. This 
serves to directly relate the key attributes. Cardinalities can be shown for each attribute, 
meaning the minimum and maximum occurrences of the attribute as it relates to a single 
instance of the object. The cardinalities are designated to the right of each attribute by the 
two values separated by a hyphen. The minimum cardinality is the left value, the 
maximum the right. 
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Figure 3. Primary Objects of MCER C Model 

Figure 3 depicts a Semantic Object Model with only the four objects of a simple 
survey system that allows for management of multiple surveys and respondents. These 
primary objects, while modeling the basic ideas of a simple survey system, are insufficient 
to handle all the problems associated with the USMC Census database. Other objects 
must be added to the model to handle issues surrounding the management of a large, 
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longitudinal survey. These additional objects will be described below. The following is a 
description of the basic objects, their associated relationships, and their key attributes. 

The SURVEY object models the survey instrument. The SurveyName field is the 
uniquely identifying key for a SURVEY, and will be either the Exit survey or Retention 
survey for the USMC Census database. A SURVEY consists of many QUESTIONS, and 
many RESPONDENTS can take a particular SURVEY. This is not modeled directly, 
however, rather the RESPONSE object is used to capture the relationship between 
RESPONDENT and SURVEY. While one SURVEY can have many QUESTIONS, the 
business rules pertaining to survey questions will determine whether QUESTIONS can 
pertain to one or many SURVEYS. In order to reuse QUESTIONS, they must be 
associated with many SURVEYS in this model. 

QUESTION is a separate object from SURVEY because questions can take many 
forms, and each survey can take many forms with varying numbers and types of questions. 
This relationship is necessary to provide the flexibility to manage multiple surveys. If 
questions were only a field within a survey, then each question developed could only be 
used for one survey. With the separation of the objects, questions can be reused. The 
VariableName field uniquely identifies a QUESTION and is therefore the key for this 
primary object. 

RESPONDENT is a separate object that captures the notion there will be 
individuals taking the survey and providing responses which we want to measure in this 
application. For the purposes of this database, certain attributes of respondent information 
require protection under the Privacy Act of 1974; treating RESPONDENT as a separate 
object facilitates the protection of this stored data. Certain demographic and personal 
information obtained for this object in the MCERC database is extracted from the USMC 
master file rather than entered directly by the respondent. The primary key of the 
RESPONDENT object is the SSN field (Social Security Number), with the Name of the 
respondent being a secondary identifier. Only the last four digits of the SSN are used to 
establish relationships with other entities. 
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RESPONSE is a separate object, and represents the key data elements of interest 
for analysis in this database. Determining the best way to handle this object depends on 
the choice of business rules for this system. One approach, in which questions for each 
version of SURVEY are viewed as relating only to that particular survey, is to treat each 
response as one RESPONSE object for each RESPONDENT for each SURVEY. This 
would appear as a sequential list of answers. Another view, which is adopted here, allows 
each particular QUESTION to be used on many surveys, in varying sequence, and in 
various versions. In this case, the RESPONSE object appears one time for each 
QUESTION for each RESPONDENT for each SURVEY answered. This requires 
significantly more computing and storage overhead as a tradeoff against more usability 
and flexibility in the system. Each RESPONSE is uniquely identified by a combination of 
the key fields of SURVEY, QUESTION, and RESPONDENT. The key for RESPONSE 
is therefore a combination of the keys of these three objects. 
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Figure 4. Entity-Relationship Schematic of Simple Survey System 

The next step we take is to convert the basic semantic object model shown in 
Figure 3 into a database schema, in this case a Microsoft Access database. This gives an 
explicit representation of the relationships between the entities that result from the SOM. 
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Figure 4 shows the resulting tables and relationships between the tables. In this model, the 
SURVEY table has a one-to-many relationship with RESPONSE, meaning a single 
SURVEY can have many RESPONSES and a single RESPONSE pertains to one and only 
one SURVEY. 

SURVEY is also joined via a junction table to QUESTION, reflecting a many-to- 
many relationship. A single SURVEY will have at least one, but may have many 
QUESTIONS. Likewise, a single QUESTION will pertain to at least one, but may be 
asked on many SURVEYS. 

Another many-to-many relationship exists between SURVEY and 
RESPONDENT, with RESPONSE serving as a junction table in this case. In the model, 
we could have created a direct relationship between RESPONDENT and SURVEY, but 
this would have been redundant, since the relationship is already captured via the 
RESPONSE table. A single SURVEY can have many RESPONDENTS, and a single 
RESPONDENT can respond to many different SURVEYS. 

The QUESTION table has a similar redundant relationship at first glance. The 
many-to-many relationship between QUESTION and SURVEY has already been 
discussed. The RESPONSE table also relates these two objects in a many-to-many 
relationship. However, for a RESPONSE to exist, there also has to be a RESPONDENT. 
QUESTIONS and SURVEYS will exist before there are any RESPONDENTS. The 
redundancy here is necessary to manage surveys and questions prior to having any 
responses by respondents. The survey designer must create a SURVEY and associated 
QUESTIONS first in order to later obtain RESPONSE and RESPONDENT information. 

A single instance of a QUESTION can have from zero-to-many RESPONDENTS. 
Likewise a single RESPONDENT will answer one-to-many QUESTIONS. This creates a 
many-to-many relationship between QUESTION and RESPONDENT, which are joined 
via the RESPONSE table. A single instance of QUESTION can have many RESPONSES, 
but a single RESPONSE pertains to one and only one QUESTION. A RESPONSE is 
defined as one respondent’s answer to one QUESTION of one SURVEY. Although 
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RESPONSE serves as a junction table for the above-mentioned many-to-many 
relationships, a single instance of RESPONSE can pertain to one and only one 
QUESTION, SURVEY, and RESPONDENT. Therefore each RESPONSE is uniquely 
identified by the combination of the keys of the other three objects. The RESPONSE 
object represents the ultimate target of the survey system, which is to gather many unique 
responses for analysis. 

2. Refinement of the Data Model for Longitudinal Surveys 

The foregoing SOM and resulting diagram of its resultant relationships provide the 
basis for a simple survey system, yet will not suffice for a large, longitudinal survey system 
like the USMC Longitudinal Censuses for Exit and Retention (MCERC). There are 
complex issues which complicate the implementation of the system, and which require 
decisions about how to manage the complexity. Additional objects will have to be added 
to the model, requiring more tables in the database, and further analysis of the 
relationships. 

There are at least three complicating issues caused by the size and the longitudinal 
nature of the system. First among them is version management due to the longitudinal 
nature of the survey and the necessity to facilitate change. Secondly, conditional 
branching results from the requirement that various subsets of the targeted respondents 
need answer only those questions pertinent to their demographics, or questions that are 
only applicable contingent upon answers to previous questions. Related to this is the third 
issue of sequencing the questions between different versions of surveys and the different 
subsets of respondents who will see them. 

The longitudinal nature of MCERC creates the requirement for version 
management. Changes to surveys that span many years are inevitable. Responses to 
certain questions are very likely to prove too erratic for insightful analysis, and such 
questions will be refined, rewritten, or even eliminated. This entails management of 
various versions of what is essentially the same question, and management of a new 
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version of the actual survey every time a change is made to the survey in any meaningful 
way. Even without any changes in the actual survey involving its appearance, wording, 
sequence, etc., over the years of implementation, it may still be desirable to have each time 
period represent a different version of the survey. For instance, the USMC Retention 
census will be taken annually by most Marines between May and September. Each year 
could be considered a different version for ease of management, although the dating of 
survey responses renders this unnecessary. 

Conditional branching occurs in MCERC based either on demographics of 
respondents, or their responses to conditional questions. For example, some questions are 
to be answered by officers only, and some by enlisted only. If the information on the 
respondent indicates he or she is an officer, then the enlisted only questions will not be 
presented to him or her. This is an example of conditional branching based on 
demographics. A question about family housing support will not be asked a Marine who 
first answers that she lives in the bachelor barracks. This is an example of conditional 
branching based on a previous response. 

The problem of sequencing questions in a complex and changing survey system 
like MCERC is a result of changing sequence as new versions are fielded, and maintaining 
a desired sequence between respondent subsets related to branching. A good survey 
system should keep questions in the same sequence to manage variance in responses. This 
simplifies the problem a great deal, since all demographic groups within the overall 
respondent population are answering essentially the same survey. If the general sequence 
is changed for a subset of respondents, this essentially creates a different survey. 

3. Business Rules 

Given the simple survey system described previously and the complicating issues 
discussed above, a set of business rules needs to be defined for MCERC. Once the 
business rules are initially identified, the data model and relational database schema can be 
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revisited for solutions to the problems. Table 3 displays the relevant business rules for 
MCERC. 



1 . 


A RESPONDENT can take multiple SURVEYS, including both Retention and Exit surveys. 


2. 


A RESPONDENT answers any given version of a SURVEY one time only. 


3. 


When a RESPONDENT takes a SURVEY, he or she only answers QUESTIONS related to that 
particular SURVEY. 


4. 


A QUESTION can appear on multiple SURVEYS. 


5. 


A QUESTION can be modified, but only one version of it will appear on one version of a 
SURVEY. 


6. 


Once a QUESTION is modified and placed on a SURVEY, there is a different SURVEY version as 
well as a different QUESTION version. 


7. 


Every QUESTION in the database must be associated with a SURVEY. (No excess, unused 
questions will be kept in the system). 


8. 


Merely changing the sequence of a QUESTION without changing the wording does not create a 
new QUESTION version, but does create a new SURVEY version. 


9. 


QUESTIONS may have varying numbers of choices and may come in a variety of formats. 


10. 


RESPONDENT’S personal, private information will be protected from uncontrolled access. 


11. 


RESPONSE data will be accessible for longitudinal analysis. 



Table 3. Business Rules for MCERC 



Clearly, if a Marine is taking a Retention survey, he or she is expected to be in the 
service for the opportunity to take another survey of either type. The expectation that a 
Marine can take multiple Exit surveys is justified by the possibility of “broken time”, 
where a Marine exits the service and later returns, eventually to exit again. There is also 
the possibility the Exit survey will be completed, and circumstances will subsequently 
change before the Marine actually exits. Such circumstances as a full-scale deployment 
for a combat situation, unexpected promotions or billet opportunities, or simple changes 
of attitude due to personal circumstances have the potential to keep a Marine in the 
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service after completing an exit survey. Although this is a rare situation, the capability to 
support it must be available in the survey system. 

4. Conceptual Data Model for Longitudinal Survey System 

Now that the basic model and relationships have been described, the basic model 
can be modified to accommodate the business rules complexities of a longitudinal survey 
system. With respect to version management, both SURVEYS and QUESTIONS are 
highly likely to encounter changes in a survey project spanning an indefinite period of 
time, presumably many years. The Archetype/Version object provides the solution to 
version management of SURVEYS and survey QUESTIONS. [Kroenke, 1995] The 
archetype object is represented with the common attributes the object will have, and the 
version portion has the changing attributes, such as a version number. Thus it is a 
composite object with the primary object having from one-to-many version objects 
associated with it. Figure 5 shows the Semantic Object Model for MCERC including this 
technique. 

Also included in Figure 5 is a new CHOICESET object. The business rules allow 
for multiple formats for QUESTIONS, meaning they may be multiple choice, true or false, 
free text entry, numerical entry, etc. CHOICESET is related to the QUESTION object 
via the new QUESTIONVERS object, where QUESTIONVERS is the version portion of 
the archetype/version object for questions. As the model shows, a CHOICESET can be 
used on one-to-many QUESTIONVERS objects, and a QUESTIONVERS will have one 
and only one CHOICESET object associated with it. The unique identifier for the 
CHOICESET is the key attribute ChoiceSetlD. Note that there is a Choice attribute in 
the RESPONSE object, yet there is no relationship between RESPONSE and 
CHOICESET. CHOICESET is a part of the QUESTION/QUESTIONVERS object, and 
only provides a mechanism for the Respondent to make her choice. A value for Choice is 
independently entered for each RESPONSE. It could have just as easily been called 
“Response”, “Answer”, or “Reply.” 



29 



E5 SURVEY 







(3 $SurveyName i-i 
0 Description 
. S ISURVEWERS] 



11 SURVEYVERS 

°o $SurveyVer$ionID ^ 
IE [SURVEY [ t .i 
0 VersionNo 
0 Manager ^ 

0 VsDetail q.-j 



0 RESPONSE 



jj m [RESPONSE | q.n 



0 QUESTIONVERS h. N 



-ta QUESTION ' 

0 $QuestionName m 
0 Description o-i 



a IQUESTIQNVERS 



1-N 



0 QUESTIONVERS " ; 



°a $QuestionVersionlD i.i ^ 

0 lQUESTl5Fil i.i 

0 VersionNo m 
0 Format m 
0 QDetailo.i 
0 Question m 
HI IRESPONSE 1 q.n 
0 ISURVEWERSI |. n 
0 ICHOICE SET | M 



m ^RESPONDENT I M 
0 ^QUESTIONVERS | m 
0 * |SURVEYV£RS | V1 
0 *DateStamp j.j 
0 Choice m 



0 RESPONDENT 



IS CHOICE SET • 



0 $ChoiceSetlD i.j 
°q Choice i.n ^7 

0 $ChoiceN umber ^ 
0 ChoiceDescription m 
0 IQUESTIQNVERS 



1-N 



0 $SSN M 
0 *Name m 
°° Demographics m ^ 
0 Gender ^ 

0 BirthDate m 
0 Race m 
0 IRESPONSE ] i.h 



Figure 5. MCERC Model with Archetype/V ersion Objects 

Figure 5 further illustrates the object for surveys is now broken into two objects, 
SURVEY and SURVEYVERS. The SURVEY object describes only the basic idea 
behind a survey with a particular name, but as can be seen, it can have many 
SURVEYVERS objects associated with each instance of it. Each SURVEYVERS has a 
unique identifier composed of the identifier of the archetype object and a version number. 
The relationships of SURVEYS with other objects are now via the SURVEYVERS 
object. The archetype SURVEY object is only related to the version SURVEYVERS 
object. 

Similarly, the object for questions is also broken into two objects, QUESTION and 
QUESTIONVERS. If a QUESTION is re- worded or otherwise altered without changing 
the essence or intent of the question, the archetype/version object allows it to retain the 
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same basic identifier. The QUESTIONVERS object will also retain the basic identifier of 
the QUESTION object, but will require a new, unique version number. Relationships 
between questions and other objects of the system are now via QUESTIONVERS, the 
version portion of the QUESTION/QUESTIONVERS Archetype/Version object. 




Figure 6. Entity-Relationship Schematic of Longitudinal Survey System 

The entity-relationship schematic resulting from the full model with 
Archetype/Version objects is depicted in Figure 6. As can be seen, the SURVEY and 
QUESTION archetype objects have a simple one-to-many relationship with their 
respective version objects, SURVEYVERS and QUESTIONVERS. 
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B. 



RELATIONAL DATA MODEL 



Data modeling can also be accomplished for the system using the relational model. 
This technique corresponds directly to the relations that will appear in a relational 
database, unlike the SOM, which models the objects as they are perceived in reality, 
separate from the database. 





MCERC Relational Model 


SURVEY 


(SurveyName. Description) 


SURVEYVERS 


(SurvevName FK, VersionNo. VsDetail. Manager. ED ) 


QUESTION 


(VariableName. Description) 


QUESTIONVERS 


fVariableName FK. VersionNo. Format. Ouestion. Odetail. 
ChoiceSetID_FK, ED_) 



SURVEYVERS_QUESTIONVERS_X 

(SURVEYVERS ID FK . OUESTIONVERS ID FK . Sequence, 



Condition) 




CHOICE_SET 


fChoiceSetlD. ChoiceSetDescription) 



CHOICE_SET_Choice (ChoiceSetID FK . ChoiceNumber. ChoiceDescription, ID_) 



RESPONDENT 


ISSN. Name, Gender, Birthdate, Race) 


RESPONSE 


CSSN FK. SURVEYERS ID FK. OUESTIONVERS ID FK. Datestanro. 
Choice, ED_) 




Figure 7. MCERC Relational Model 



The relational model in Figure 7 depicts each relation with the attributes or 
combinations of attributes (keys) which uniquely identify it underlined. Those relations 
having the "ED_" attribute need it for indexing, because they are associated with another 
relation with a composite key. The relations of this model correspond to the tables 
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represented in Figure 6, which shows the relationships between the tables more 
graphically. 

C. INTER-RELATIONAL CONSTRAINTS 

The foregoing models describe objects or entities and the relationships between 
them. However, they do not illustrate the inter-relational constraints. In one-to-many 
relationships, a row in a "parent" table can have many associated "child" rows in a child 
table. These relationships can be constrained as to whether or not a parent must have at 
least one child, or whether or not a child must be associated with a parent. Thus there are 
4 classifications of the inter-relational constraints: Mandatory to Mandatory, Mandatory 
to Optional, Optional to Mandatory, and Optional to Optional. These inter-relational 
constraints must be enforced to maintain data integrity. Table 4 gives these inter- 
relational constraints for the MCERC system. 



Parent 


Child 


Constraint 


SURVEY 


SURVEYVERS 


Mandatory to Mandatory 


SURVEYVERS 


RESPONSE 


Mandatory to Optional 


SURVEYVERS 


SURVEYVERS_QUESTIONVERS_X 


Mandatory to Mandatory 


QUESTION 


QUESTIONVERS 


Mandatory to Mandatory 


QUESTIONVERS 


RESPONSE 


Mandatory to Optional 


QUESTIONVERS 


SURVEYVERS_QUESTIONVERS_X 


Mandatory to Mandatory 


CHOICE_SET 


QUESTIONVERS 


Mandatory to Mandatory 


CHOICE_SET 


CHOICE_SET_Choice 


Mandatory to Mandatory 


RESPONDENT 


RESPONSE 


Mandatory to Mandatory 



Table 4. Inter-Relational Constraints in MCERC 

For the Archetype/ Version objects composed of SURVEY/SURVEYVERS and 
QUESTION/QUESTIONVERS, there are Mandatory to Mandatory inter-relational 
constraints. A version object must have an archetype and in MCERC, there will be at 
least one version required for each archetype; thus the inter-relational constraints exist to 
enforce this. 
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Whenever a survey is created, there must be at least one question associated with 
it. Likewise, whenever a question is added to the database, it must be associated with a 
survey. Therefore, junction table SURVEYVERS_QUESTIONVERS_X that associates 
QUESTIONVERS and SURVEYVERS has Mandatory to Mandatory inter-relational 
constraints with both of these relations. 

Whenever a question is placed in the database, it must have a set of choices 
associated with it. The CHOICE_SET relation is required to have at least one related 
QUESTIONVERS to avoid having unused sets of choices in the database. The inter- 
relational constraint is again Mandatory to Mandatory. 

Because CHOICE_SETs may have varying numbers and types of choices, the 
CHOICE_SET_Choice relation defines all the choices that can be associated with a set of 
choices. This is also defined as a Mandatory to Mandatory inter-relational constraint. 

The RESPONSE and RESPONDENT relations represent another aspect of 
MCERC, the data being gathered after development of the actual survey instrument. The 
inter-relational constraint between these two relations is clearly Mandatory to Mandatory. 
A RESPONSE must have a RESPONDENT, and a RESPONDENT cannot be possibly 
defined until he/she has provided a RESPONSE. 

The other two relations associated with RESPONSE are SURVEYVERS and 
QUESTIONVERS. Because surveys and questions must be written and made available to 
potential respondents before responses can be gathered, there cannot be a response 
initially. However, a response is clearly related to a question, which is required to be on a 
survey. Thus, the inter-relational constraint between SURVEYVERS and RESPONSE is 
Mandatory to Optional. Likewise, the constraint between QUESTIONVERS and 
RESPONSE is Mandatory to Optional. 

The constraints defined in the data model and schema maintain the appropriate 
data integrity of the underlying survey management database. At the same time, the model 
is flexible enough to accommodate the complex problems of a longitudinal survey. 
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D. MICROSOFT ACCESS DESIGN/DATA DICTIONARY 



The design of the Access database results from the relational model defined in this 
chapter. Building the Access database first required the analysis of entities and 
relationships as discussed previously, and the creation of a data model. The data model 
was then implemented in the SALSA for the Desktop software from Wall Data, Inc., a 
Computer Aided Software Engineering (CASE) tool for creating database applications, 
either in SALSA database or other well-known applications such as FoxPro or Access. 
To create the application, the user develops objects with attributes in SALSA. The model 
simply describes the data. From this model, SALSA for the Desktop will generate the 
basic tables and relationships of a database application for the user. Once this was 
accomplished for MCERC, the database application development required alterations of 
fields in the tables to ensure appropriate keys, indexes, and data types existed. Enforcing 
some inter-relational constraints required designing forms to restrict data entry for certain 
fields, particularly where the constraints were designated to prevent unused records from 
existing in the database. 

When SALSA is used to generated the Access database for MCERC, the unique 
identifiers of the SALSA model are not translated into the key fields of the Access 
database schema. Instead, each table is automatically given a numeric field named “ED_.” 
Although it is possible to use these as the key fields, it is desirable to designate meaningful 
key fields with an actual attribute that uniquely identifies the table. Therefore, the key 
attributes designated in the original model are re-designated as the key fields in the Access 
schema. Further definition of fields is required to ensure proper constraints are enforced 
by Access. In particular, the key fields must be defined as indexes and specified as to 
whether or not duplicates are allowed. Data integrity constraints such as these must be 
defined for all fields. 

Data integrity constraints must be identified and enforced in the model for 
successful implementation. The data dictionary in Appendix B is provided to identify the 
data types of each attribute and give any pertinent constraints on the database fields. In 
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addition to data types, the length of each field must be defined. In most cases, the length 
is given by a numerical figure, but in the case of fields defined as "Number" data types, it 
can be given as "integer, long integer, byte, single, or double." 

Once all key fields of the tables are defined properly, other fields are also reviewed 
to ensure the data types, field lengths, "required" flags, or other desired field properties 
are set correctly. For MCERC, the design view in which this is accomplished for the 
" Question VersionID_VersionNo" field of the QUESTIONVERS table is shown in Figure 
8. (Note the triangular selector preceding the Field Name, designating the active field.) 
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Figure 8. Design View/Table Definition of Table QUESTIONVERS of MCERC 

The SALSA model generated the fields in the table, although the key fields had to 
be re-designated, because SALSA generated the "ID_" field for Access as the key. In the 
SALSA model, the composite key "QuestionVersionID" in the QUESTIONVERS object 
of the model was the unique identifier of the object. The QUESTIONVERS table in the 
database schema is generated with the two fields "QuestionVersionID_ 



36 




QuestionName_FK" and "QuestionVersionID_VersionNo" corresponding to the two 
fields of the composite key from the SALSA model. This key prevents having records in 
this table with the same combinations of "QuestionVersionID_QuestionName _FK" and 
"QuestionVersionID_VersionNo." The "ID_" field is retained as a unique index for the 
table, although it is not a key field. It is used to establish the many-to-many relationship 
between the QUESTIONVERS and SURVEYVERS tables. 

Duplicate values of the "QuestionVersionID_VersionNo" field must be allowed so 
that all questions may have a version 1, version 2, etc. In Figure 8, this field is selected so 
the "Field Properties" at the bottom of the screen apply to the version number field of a 
question in the QUESTIONVERS table. Screens defining all field properties are displayed 
in Appendix B. Using these screens, all fields are given appropriate definitions to 
correctly implement MCERC. 

One difficulty involves the "VersionNo" fields of the QUESTIONVERS and 
SURVEYVERS tables, which must be incremented by one for a new "QuestionName" or 
"SurveyName". Although the AutoNumber data type increments by one every time an 
entry is made in the field, it increments regardless of the associated name. Therefore, the 
AutoNumber data type does not provide the solution. To correctly implement the 
requirement, the database application must not allow a user to enter a value in the 
"VersionNo" field other than the next consecutive number relative to the selected primary 
identifier. For MCERC, this simply means that the application must require a Version 2 
when there is only a Version 1 of either the Exit or Retention survey, or of a given 
question. 

E. POPULATING THE TABLES WITH DATA 

Once the database schema has been designed as described, populating it with data 
constitutes the actual building of the database. For MCERC, this entails two basic 
procedures; entry of the survey instrument, and entry of response data. First the survey 
instrument data must be entered using Access forms to input the surveys and questions, 
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associating all questions with a survey. The first such entry necessarily entails all fields of 
the Access schema except for those specific to the RESPONDENT and RESPONSE 
tables. This is due to the inter-relational constraints defined previously. Therefore, the 
first entry will have Version 1 of a Survey, with entries in all fields of the SURVEY and 
SURVEYVERS tables. It will have Version 1 of the first question to be entered, along 
with entries for all fields of the QUESTION, QUESTIONVERS, CHOICE_SET, and 
CHOICE_SET_Choice tables. This entails entry of the first set of choices, which must be 
done in order to have a question defined. The junction table, 
SURVEYVERS_QUESTIONVERS_X, representing the many-to-many relationship 
between questions and surveys will have the key fields for the relationship automatically 
populated and entries made for all required fields. This initial data entry requires a 
complicated set of inter-related forms and linked forms to be designed as part of the 
interface (see Chapter V). 

The primary form designed to accommodate this initial data entry is displayed in 
Figure 9. The user enters the name of the first survey, which is Version 1 by default. A 
description of the general purpose of the survey is then entered, as is the name of the 
surveyor or "Manager." Because this is the first entry, there are no questions displayed in 
the field designed for the selection of existing questions. Of the two buttons at the bottom 
of the form, the "Create a New Question" button should be chosen. This button takes the 
user to a form to accomplish this entry, which has a similar button to create a new set of 
choices to associate with the question. The development of the User Interface will be fully 
explained in Chapter V, which will clarify the method for populating the database with all 
elements of the survey instruments. 

Questions will be entered via forms that require their association with a specific 
survey version. When the second survey is developed, all questions will be available on 
the form in Figure 9 to choose from as the first question associated with the survey, or the 
user may create a new question, or version of an existing question, using the same form. 
A similar form allows subsequent versions of existing surveys to be entered. 
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Figure 9. Data Entry Form for the First Version of a Survey 



The other aspect of populating the database involves the procedures for getting the 
response data into MCERC. As the USMC Surveys are currently implemented, the 
responses are appended to a response database as respondents provide them. M&RA 
maintains this database separately from other data about the surveys. There is a file for 
responses to the first version of both the Exit and Retention surveys. Data from these files 
must be obtained in the format of the RESPONSE relation for establishing relationships 
between the data and the survey instrument in MCERC. However, for analysis, it must be 
converted into a matrix with each row representing a respondent's set of answers for an 
entire survey. 

Data is currently received for MCERC in the format shown in Table 5. This is an 
Access table, so it can be related directly to the tables in the database to implement the 
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schema. It simply needs to be imported into the database first, then have the appropriate 
relationship established. It can then be queried along with other tables to relate responses 
back to questions and surveys. In this initial implementation of MCERC, the user of the 
system must know which survey and version the data file is from. A column must be 



added to the table and populated with this information to establish all relationships. Once 
the database knows which version of the survey a response record is for, it can associate 



the version of the question that was actually asked for that response. 
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Table 5. Data Extract of Responses to USMC Retention Census 

A sample of the actual data from Version 1 of the USMC Retention Survey is 
given in Table 5. This layout for the data is clearly redundant, with the SSN and 
DateTaken being identical for all records of one Marine's responses. More redundancy 
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occurs when the column is added for the survey version, which will be the same for all 
responses from all respondents who take a given version of a survey. This redundancy is 
eliminated for the response data analysis aspect of the system. 
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Table 6. Subset of Response Data after Conversion from RESPONSE Table Format 



After conversion, the data is in the general format of Table 6. However, there are 
currently over 270 columns required to represent all questions. Each row of the table 
represents one respondent's submission of survey responses. The date/time in the second 
column, combined with the SSN (last 4 digits) in the first column, uniquely identifies a 
submission of responses to one survey for one respondent. A column must also be 
included which will contain the Survey for which all responses are submitted. Under the 
assumption that a survey version is only given during a particular year, the date/time and 
survey version might be substitutable as an identifier when combined with the SSN. 
Clearly, the redundancy of the previous format is eliminated here. This format is 
preferable for permanent storage, but the format of the RESPONSE table (similar to Table 
5) must be used for relating responses to the survey instruments in the database. 



41 



F. 



DATABASE ADMINISTRATION 



Several issues need to be considered on a continuing basis to ensure the overall 
data integrity of the database, particularly the responses, which compose the critical 
information desired for future analysis. As the system evolves, access via the Internet with 
concurrent, multiple users will very likely become an issue. The general issues of security, 
protection and preservation of the database needs to be a primary concern of the database 
administrator. 

1. Security 

One of the primary concerns for granting access to MCERC is security. Security 
is a two-sided issue regarding the survey data. Data integrity must be considered when 
determining how the data will be made available. If certain users are granted access 
directly to the database, strict guidelines must be established and followed to ensure the 
data is not rendered unusable by viruses or other malicious software that could potentially 
be unleashed during a query of the database. Privacy must also be considered, because of 
the information that will be maintained on individual respondents. Respondents must be 
assured that their responses will not be traced back to them, so they will be more likely to 
respond with total honesty and candor. Additionally, some may fear that certain personal 
information combined with their social security number will make them vulnerable to theft 
and misuse of the information. 

cl Data Access 

Good data integrity is contingent upon well-controlled data access to the 
response database. The data access issue can be handled in at least two ways. A less 
expensive, but more secure way is to implement strict filtering of any queries on the 
database. Parties requesting MCERC information should be granted access on a limited 
basis. Users should be required to provide information that verifies who they are, why 
they need the data, and what they plan to do with it. They may then be issued a password 
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and account identification (username, account number, etc.). Upon entering and querying 
the system, each request would be scanned by virus protection software. All queries 
attempted would be logged into an audit file in order to trace what information is being 
requested and by whom. 

Another method for handling the data access issue is to allow no access 
directly to the stored data. In this scenario, all queries would be handled by a proprietary 
application for processing queries against the database. Queries could be sent via a web- 
based front-end and pre-screened and processed to ensure no malicious software could 
infect the data. There would still be a need to ensure authentication of users in order to 
enforce privacy with additional levels of authentication required for sensitive data. 

b. Privacy 

The issue of privacy can be handled in multiple ways. Strict authentication 
and limiting access as discussed relative to data integrity is one method, but those with 
access can still potentially compromise the information. A better solution for the privacy 
issue is to ensure personal information maintained as data cannot be traced to the actual 
person submitting it. One way to accomplish this entails generating a unique identification 
number for each respondent. This generated user ED (GUTD) would be permanently 
assigned to the respondent by a linked list maintained at the website which associates 
specific identifying information (Social Security number) with the GUID. This table 
would have to be protected from access as any confidential information is, but would 
provide specific identification of a respondent relative to all responses submitted to the 
Exit and Retention Censuses without betraying the identity of the respondent. 

Another possible solution is the use of cryptography when the data is 
retrieved. The data may be maintained with private information, but when it is retrieved, 
the same algorithm is run only on all "SSN" fields retrieved. Other data would not be 
encrypted. Since the same algorithm encrypts all instances of "SSN" retrieved, all of one 
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respondent's data will be recognizable as longitudinal data coming from a unique 
respondent. 

To achieve data privacy and integrity, the basic requirements are that the 
system have secure communications between authenticated agents. [Cain, 1999] In the 
alternatives above, the authentication is handled prior to allowing access to any data. The 
communications interface between the querying system and the data must be inherently 
secure. 



2. Database Backup and Recovery 

As with any important information, the MCERC database must be protected from 
loss. The simplest way, giving the user a flexible alternative for storage locations, is to 
periodically copy the complete file to an external storage device. This method copies all 
data, table structure, forms, queries, etc. associated with the database. To recover from 
losing information in the working file, the user makes a copy from the external storage 
device back to the working drive. However, all information entered since the previous 
save must then be restored, so copying frequent backups to external storage during data 
entry is important. 

Another approach to backup and recovery is to maintain a copy of the database 
schema on disk, and only back up the tables, since they contain the desired data. This 
procedure can be executed by transferring the tables to an external database file for 
backup. To recover when needed, the database schema can be reinstalled from disk, and 
the procedure for transferring the tables performed on the external file. This gives the user 
the structure of the database, and all the data from the external file since the last backup. 
This procedure is somewhat more onerous than simply restoring a backup. 

There are three potential scenarios for the database administrator to consider for 
the survey instrument database. The first is a stand-alone system maintained locally by 
surveyors who design the surveys. The backup and recovery alternatives discussed above 
apply mainly to this scenario, since this is the logical beginning one for MCERC. 
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Another potential scenario is that the database would reside on a local server and 
be accessible by multiple users. If the database were split, with only the data tables 
maintained on the server, then only the data tables would need to be backed up to an 
external storage device. If the server is lost, then all data is still available from the last 
backup. Splitting the database means it is divided into two files: one that contains the 
tables and one that contains the queries, forms, reports, macros, and modules. By splitting 
the database, users who need to access MCERC can customize their own forms, reports, 
and other objects while maintaining a single source of data on the network. The database 
administrator needs to ensure that there are routine backups performed on the server to 
preserve the data. The normal procedure would be a daily backup to an external storage 
device during off-peak hours. Recovery in the event of data loss would require access to 
the external storage device. If transaction logs are kept for all backups from the server, 
and if each user has a transaction log recording their daily transactions, then users will 
know which of their transactions need to be re-entered into the database after the server is 
restored. 

The third possible scenario involves replication of the database. Multiple users can 
have a working copy (replica) of the data files. Any changes made by users are updated 
when the users connect to the network with the master database, called the "Design 
Master" by Access. A replica can be maintained on a network computer, effectively 
creating an automatic backup. Whenever a user of a replica "synchronizes," the changes 
are updated to the Design Master, and the updates from all other replicas to the Design 
Master are made to the user's replica. Therefore, in the event of data loss, recovery can be 
done via the Design Master. 

3. Record Locking Strategy 

Because of the large size of the survey instrument, it is conceivable that MCERC 
could be deployed in a multiuser environment. Microsoft Access can automatically prevent 
users from changing records before another user has finished editing them. However, it 
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seems unlikely that multiple users would attempt to edit the same record, so a very 
restrictive record-locking strategy is not called for. 

A good locking strategy for MCERC would allow users to finish making changes 
they have started. Since MCERC has a data field for explanatory information about 
versions of questions, this strategy would enhance collaboration because users can give 
the logic behind any editing done as a basis for discussion should other users have an 
interest in the edited record. The "Edited Records" option for a locking strategy locks the 
record being edited, so no other user can change it. If another user tries to edit a record 
that is locked, Access displays a locked record indicator. This strategy ensures that 
changes once begun can always be finished. 
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V. 



BUILDING THE INTERFACE 



A good user interface should make the complexities of the database schema as 
transparent as possible to the user. For MCERC, the interface must not only handle the 
complexities of a large, longitudinal system, but must also provide the user access to 
analytical tools. MCERC provides a link to Cognos Powerplay™ for crosstabulation 
analysis of the survey data. Therefore, the user interface must provide two main avenues 
for the user: development and management of the survey instruments in Access, and 
manipulation and analysis of collected response data. Analysis can be done within MCERC 
using the link to PowerPlay or by generating a text file for importation into as statistical 
analysis the application. 

For developing and managing the survey instrument, Access provides the 
"Switchboard Manager" add-in which facilitates menu driven user interfaces to the forms 
and reports the developer designs. It is possible to use this Access feature to run macros 
that will open other applications. For instance, Powerplay can be opened from the Access 
switchboard. Users, in general, will either want to modify a survey instrument, or perform 
some kinds of analyses; therefore, the main interface allows the user to open Access or 
Powerplay as appropriate. It also provides a function to first convert data into a text file 
for analysis in Powerplay. This text file may be imported by other statistical analysis 
applications such as SAS™ or SPSS™. When Access is opened, the Switchboard is used 
for the menu driven portion of the interface to manage survey instruments. Visual Basic 
6.0 is used to develop the main MCERC interface between Access and Powerplay, 
including the function to prepare the data for analysis as a response matrix in a text file. 

A. MODELING THE PROCESS 

Building the Access database initially required the analysis of entities and 
relationships, and the creation of a data model. Similarly, the building of the user interface 
is preceded by the development of a process model. Once models of the process and sub- 
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processes are developed, the design and implementation of an interface can follow in a 
structured manner. 

It is essential to develop a thorough understanding of the processes that must 
logically occur in the system. One method for gaining this understanding results is to 
simply think through all processes desired of the system, and determine what must take 
place to accomplish them, taking a step by step approach. Each step of the process is 
visually represented as a module beginning with the first step and linking all steps that can 
then be taken. The resultant process decomposition diagram is a model of the process 
providing an excellent visual aid for developing a user interface. It helps answer the 
question "What next?" and aids the developer in understanding the inputs and outputs of 
each module. The level of detail required in a process decomposition diagram is 
dependent upon the complexity of the requirements of the system being developed. 



The main process for using MCERC involves two major avenues, working with 
survey instruments, and data analysis (Figure 10). 




Figure 10. Main Process Decomposition Diagram for MCERC 
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There are clearly more levels of detail than shown in Figure 10. For the purpose of 
developing a user interface for MCERC, there is sufficient detail beneath the "Analyze 
Response Data" module since the user interface primarily entails accessing the Cognos 
Powerplay™ software. Once there, the subsequent functions are accomplished via the 
Powerplay interface, with one exception. Aji interface for converting data into a matrix 
must be developed. 

There is much more detail needed beneath the "Build Survey Instruments" module, 
however. Understanding the database schema and the relationships that must be enforced 
within it helps to understand how the sub-processes beneath these modules must interact. 
Each of the processes beneath is broken down further in subsequent process 
decomposition diagrams. 




Figure 1 1 . Process Decomposition for Generating a New Survey in MCERC 
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The basic information that goes in each of the database fields for surveys 
represents the level of detail beneath the main module in Figure 1 1 . The complicating 
issue with simply defining a survey record is the constraint that a survey cannot be defined 
without associated questions. There are actually three options for doing this: Adding an 
existing question, modifying an existing one, or generating a new one. All three options 
result in the addition of a question to the survey. Likewise, modifying a question becomes 
somewhat more complex when different choice sets are assigned. An existing choice set 
may be assigned, or a new one defined and assigned. Another benefit of process 
decomposition is realized in this diagram. Note that "Assign ChoiceSet" appears twice, 
once beneath "Modify Question" and again beneath "Generate New Question." When 
designing these two processes, the same module for "Assign ChoiceSet" may be used. 




Figure 12. Process Decomposition for Generating a New Version of a Survey 
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As Figure 12 shows, generating a new version of a survey is similar to generating a 
new survey. Some of the immediate sub-processes are somewhat different, such as 
retrieving a survey archetype vice defining a new one, assigning the next version number, 
and deleting or reordering questions. However, this diagram shows that the entire process 
of adding questions is identical to that of the "Generate New Survey" process 
decomposition diagram. Therefore, that portion of the interface can be re-used to support 
both upper level processes for building surveys. 

B. DESIGN USER INTERFACE 

As the main process decomposition diagram shows, a logical starting point in 
designing the user interface process is with the initial screen the user will see when using 
MCERC. For the survey management aspect of MCERC, the initial interface screen will 
provide an option for the user to manage the survey instrument database, including 
entering data and retrieving reports. As seen in Figure 13, this initial screen will also 
provide access for the user to analyze data using PowerPlay, use Transformer to build a 
"Powercube" for analysis, or convert data sets into the matrix format. 
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Figure 13. Visual Basic User Interface Screen for MCERC 
1. Survey Management Interface 

Upon selecting the "Manage Surveys" button on the main MCERC form shown in 
Figure 13, Access opens the survey instrument database with the menu in Figure 14 as the 
active screen. The user has the choice to work on surveys, analyze data, view or print 
survey instrument information, or exit the system. Note also the option to use Cognos 
Transformer™ to create a Powercube for analysis. The option to use either the survey 
management or data analysis aspect is available to the user via this button on the 
switchboards. 
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0 Main Switchboard 
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(Marine Corps Exit and Retention Censuses) 
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Figure 14. MCERC Menu Screen in Access 



The first time MCERC is used, the logical purpose would be to generate a new 
survey. Figure 9 in Chapter IV displays the form for this action, which populates the 
database with data. A similar action, as developed in the process decomposition diagrams, 
is the generation of a new version of a survey. The form designed for this appears in 
Figure 15. 
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How important to your desire to leave is: Current retirements 








Figure 15. MCERC Form for Entry of New Version of an Existing Survey 



Survey Name and Previous Version are displayed in the list box at the top of the 
screen. As can be seen, the Retention survey, Version 1 is selected, and the field labeled 
"New Vs. #" displays a "2." This field populates the VersionNo field of the 
SURVEYVERS table when the form updates the tables. The "Description" box displays 
the data from the SURVEY table describing the basic information about the type of 
survey. The user may now enter information about Version 2 in the "Brief Description of 
New Survey" field of the form. Also, the user may document the name of the person 
responsible for this version in the "Manager" field. 

Figure 15 also illustrates that questions are associated with surveys as they are 
created. The user can choose an existing question from the list box, or may select one of 
two buttons to either modify an existing question or design a new one. Once either of 
these two actions is performed, the user returns to the list box and selects the new 
question. The default sequence of the question on the new survey is 10. By convention, 
the sequence numbers are given in multiples of 10, so a default value of 10 assumes this is 
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B1 Make New Question 



the first question for the survey. The user may identify a condition at this time also, 
meaning the presentation of this question to a respondent may depend upon other 
information about the respondent. An example of this for the USMC Surveys is "Enlisted 
Only." 

This form combines information from five tables of the database schema, 
SURVEY, SURVEYVERS, QUESTION, QUESTIONVERS, and SURVEYVERS_ 
QUESTIONVERS_X, the join table. The design enforces the interrelational constraints 
between them, keeping the database clear of excess records. Other MCERC forms are 
designed to enforce these constraints as well. The use of these forms is discussed in the 
Maintenance and User's Manual, Appendix D. 

A sub-process of generating new surveys and new survey versions is initiated when 
the user presses the "Create a New Question" button. 



Figure 16. Form for New Questions in MCERC 
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Since the form in Figure 16 is for new questions, questions created with this form 
will always be the first version. The default 1 for the version number can be seen, as can 
the default "Version 1 description" statement in the "Question Version Details" field. Like 
the process decomposition diagram showed, a new question can have a Choice set 
assigned. This Choice set can be chosen from existing ones in the "Choice Set" combo 
box field, or a new one can be designed by using the "New Choice Set" button. A very 
similar form to Figure 16 is used for the making of new versions of questions. 

To design Choice sets, some flexibility is needed. These sets do not necessarily 
contain a sequential list of Choices. Some are ordered in reverse sequence. (Figure 2 in 
Chapter III displayed some examples.) Some use "0" as a value. Because of this, the user 
must enter the values for Choice sets. The values entered are simply the Choice Set 
identifier, a description of the set if desired, and as many Choice Numbers with 
corresponding descriptions of each choice as required. Figure 17 shows the form for these 
entries. 




Figure 17. Form for Making New Choice Sets in MCERC 
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Once the user has entered all information about a survey instrument into MCERC, 
a report, called a "Codebook," can be generated with all the questions and their associated 
choices for that survey instrument. From the screen displayed in Figure 14, the user may 
select "View/Print Survey Instrument Information." This leads to an option to either 
"View/Print" a survey codebook, return to the main menu, or exit MCERC. Once the 
option to print the codebook is selected, the user is prompted for the Survey Name and 
the Version Number, and MCERC generates a codebook on the screen which the user 
may print if desired. 

2. Data Analysis Interface 

To conduct analysis on the response data, there are two main requirements; getting 
data into the appropriate format for analysis, and using Powerplay to perform 
crosstabulations analysis. Data can be obtained in its raw form, which is the format 
described by the RESPONSE object of the MCERC data model. One response is an 
answer provided by one respondent to one question on one survey on a specific date. A 
large dataset may be composed of many of these responses, representing many 
respondents' answers to all appropriate questions on multiple surveys on multiple dates. 
This data must be converted into a "flat file" or spreadsheet format, with one row 
representing all of one respondent's answers to all questions on one survey in one 
timeframe. This can then be imported into analytical software tools such as SAS™ and 
SPSS™. The Visual Basic interface must provide the ability to put the data into this 
format before Powerplay can be used. The Visual Basic code for the procedures to 
convert the data into a spreadsheet are included in Appendix C. 

Powerplay is used to analyze volumes of data across multiple dimensions. The 
information must be placed in multi-dimensional matrices according to the variables the 
analyst is examining. Called "Powercubes" by Cognos, these matrices can be designed 
with a related application, Cognos Transformer™. Once they are designed, the matrices 
can be refreshed as additional data is gathered. Therefore, the Visual Basic interface must 
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make Transformer available for the user to create desired Powercubes from data, as well 
as facilitate converting the data into the "flat file" (spreadsheet) format. 

To analyze response data from MCERC, the user first needs to have the data in a 
matrix format. This is initiated via the "Create Response Matrix" button on the main 
MCERC form (Figure 13). Once this process is completed, the user needs to create a 
Powercube with the dimensions to be analyzed and the measures desired for analyzing the 
dimension. 

For the Retention survey, an example of a Powercube would be to analyze the 
MOS dimension against different measures of leadership quality from the responses 
provided by Marines of various MOS's as to their rating of the quality of leadership of the 
officers and Non-Commissioned officers. Defining certain communities of MOS skills 
would allow multiple levels of "drill-down" in this Powercube. MOSs could be grouped 
by aviation, ground combat arms, logistics, administrative, etc. Marines of all MOSs will 
provide responses rating the quality of leadership at several levels (NCO's, SNCO's, 
Warrant Officers, Junior Officers, Field Grade Officers, and General Officers). The 
leadership is rated from Poor to Excellent on a scale of 1 to 5. Using the MOS as the 
primary drill down dimension, and the 1 to 5 rating as the measure, this Powercube can 
provide insight into how leadership is perceived overall, by different communities, and by 
each MOS. An example illustrating how the results would be viewed analyzed in 
Powerplay is shown in Figure 18. 
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Figure 18. Example Cognos Analysis of Quality Rating of Leaders by MOS 
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These numbers could be further dissected by analyzing them against another 
dimension. For example, the Unit type dimension could be in the Powercube, and the 
numbers appearing in the above matrix would reflect the unit type chosen. 

The MOS fields above are grouped by general MOS category. The analyst could 
explore further by drilling down on one MOS category to see how different MOSs in the 
field rated leaders. For example, the 0300 MOS category represents the infantry. Drilling 
down would yield each MOS within the infantry (0302, 0369, 0311, etc.). Therefore it is 
possible to find out exactly how all respondents having the same MOS rated each 
category of leaders, and to further break the result down by the type of unit of the 
respondent. Still more dimensions can be designed into Powercubes if needed. 

C. SYSTEM ARCHITECTURE 

The process of development results in the MCERC application linking Access, 
Powerplay, and Visual Basic code as an interface, as well as a small data manipulation 
program to convert data into a matrix. The application has been described throughout 
this thesis in explanations of data input and user interfaces. Appendix C contains the 
Visual Basic code for converting the data into a matrix. Obviously, the Cognos 
Powerplay™ software, including Transformer, must be installed for the application to 
have full functionality. Installation instructions are included in the User's Manual, 
Appendix D. 

Figure 19 shows the MCERC system with its various system architecture 
components and their interconnections. The Visual Basic interface component is the 
"glue" that connects the system as an integrated application. The Data Conversion 
component supports analysis by formatting the data, and is a subprogram written in 
Visual Basic. It receives input from an external response data file and outputs a text- 
based data file to a designated location. This data file can then be used by Cognos 
Powerplay or imported into another statistical analysis application. 
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Figure 19. MCERC System Architecture 

The Survey Instrument Management in Microsoft Access component is opened 
from the Visual Basic Interface for generating surveys, questions, codebooks, and other 
survey management functions. 

The Cognos Powerplay component is also opened via the interface to do analysis 
or build a Powercube for analysis. The Data Conversion component first must be used to 
create a text data file in an open location for access by Powerplay (or another statisical 
analysis application). Then Powerplay Transformer is used to build a Powercube, after 
which the analysis can be done. 

D. MAINTENANCE AND USER’ S MANUAL 



To facilitate the administration and use of MCERC, a user's manual is included as 
Appendix D. Procedures for installation, backup, and recovery are included. A step by 
step description of the system processes is given to guide the user through all processes 
included on the process decomposition diagram, except those that pertain specifically to 
Cognos Powerplay™. A comprehensive help function is included with the Cognos 
software that need not be duplicated in a User's Manual. 
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VI. CONCLUSIONS AND FUTURE ENHANCEMENTS 



Conducting longitudinal studies is not a common practice in the business world, so 
there is not a mass-marketed survey development application to support such a project. A 
proprietary application is necessary to ensure the concomitant complexities can be 
accommodated smoothly. This research designed and implemented a database system to 
support the longitudinal aspects of the USMC Exit and Retention Censuses. 

A. DESIGN AND IMPLEMENTATION CONCLUSIONS 

The data model developed for this thesis reflects the conceptual objects involved in 
a longitudinal survey system. Using archetype/version objects to capture the version 
management aspect of the problem enhances the basic Survey and Question objects. 
Having a large number of questions on the surveys is made easier by re-using the choices 
associated with questions when possible, via the CHOICE SET object. The longitudinal 
aspect is captured by the RESPONSE object, which represents the elemental data for 
which the system is designed. With this object, one person's response can always be 
traced to a specific question on a specific survey in a specific timeframe. 

The MCERC database schema implements a data model to support a longitudinal 
survey project. However, the inter-relational constraints are not all enforceable by the 
database engine as they were defined. This can be overcome by exercising control over 
data entry using validation rules, queries and coding to enforce the constraints. The 
database schema allows for tracking changes in the survey instruments relative to the 
actual responses collected by them, thereby implementing the required support of the 
longitudinal aspect of the survey system. 

Implementation of the complete database by including actual response data proved 
to be challenging. Small subsets of the response data obtained by the USMC to date can 
be retrieved from the response database via the Internet. The format very nearly matches 
the RESPONSE table format, making it fairly easy to relate to the rest of the database. 
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The conversion process developed in Visual Basic to convert the data into a usable format 
for Powerplay is very slow. However, it yields a matrix that can be used to do the analysis 
for which the surveys were intended. The link to the Cognos Powerplay application 
completes the overall survey system by giving it the necessary data analysis capability. 

B. RECOMMENDED FUTURE ENHANCEMENTS 

The MCERC application delivers the basic capability to manage questions 
forsurveys as they evolve over time. The relationship the database schema implements 
between the respondent and the survey instrument allows the tracking of a specific 
respondents' answers across the years and facilitates comparison of the responses with the 
questions. As technology continues to evolve, this survey system can be enhanced by 
moving more and more of the functionality into the web environment. 

1. World Wide Web Accessibility to DSS 

During the initial stages of the USMC Exit and Retention Census initiative, 
analysis of the data will be done by a limited number of manpower analysts, most of whom 
are located at M&RA and Naval Postgraduate School (NPS). Over time, as the volume of 
data obtained increases, accessibility to the data and the survey instrument may be of 
interest to other analysts. The Department of Defense as well as other services facing 
issues similar to those of the USMC, will likely be interested in the data. Universities 
other than NPS may assist in the research or use the longitudinal data for academic 
purposes. Policy studies organizations, "think tanks," may use the data to develop and 
justify positions on military policy issues. Therefore an area for future consideration is 
integrating the web-based survey into a single environment running exclusively on the 
Internet. 
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a. Issues 

A key concern for allowing Internet access to MCERC is security. 
Security was discussed in Chapter IV, but takes on added significance in a web-based 
environment. The issues are essentially the same, but a broader range of protections must 
be considered. Anti-virus software must be kept strictly up to date. The network 
connectivity to the system will need to be maintained for accessibility, but access must be 
restricted to those who have a valid requirement for access. 

Another issue related to making MCERC web-accessible is the system 
architecture. How to obtain data extracts, i.e., whether to download data subsets and 
store them locally vs. building and maintaining Powercubes on the remote server, and 
whether to have MCERC reside on a server or on the desktop are decisions that need to 
be made relative to this architecture. 

An attractive solution for obtaining data subsets is to access them remotely 
using the Cognos Powerplay software. The Powercubes can be built, maintained and 
refreshed on the server. For an analyst to use the data, they would merely need to know 
the remote locations of the Powercubes and be granted access. This would prevent 
proliferation of large amounts of duplicate data in various locations, and would allow for 
efficient transfer of the desired information. Rather than transferring all raw data, only the 
desired report, or aggregated data subset would be stored locally by analysts. 

If multiple individuals will be using MCERC for analyzing the survey 
instrument against the data, or are collaborating on survey design, it may become desirable 
to put MCERC on a server and have it accessible via the web. Assuming these analysts 
are geographically separated, this would facilitate collaboration, thereby speeding the 
process of developing and maintaining the surveys. 
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b. Feasibility 



Rendering MCERC accessible via the web is definitely feasible. The 
Access application can be converted to Hypertext Markup Language (HTML) or 
Extensible Markup Language (XML) using web-authoring tools as these types of tools 
become increasingly easy to use. Authorization could be granted to a limited number of 
developers to use data entry forms and collaborate on survey development if desired. 
Broader access could be granted for users desiring to pull reports from the database, such 
as listings of questions for a survey. 

The data collected by the USMC Exit and Retention Surveys can certainly 
be made web-accessible. Online Analytical Processing (OLAP) applications such as 
Powerplay Server Web Edition allow Powercubes to be deployed across the web. There 
are a growing number of OLAP software solutions available which will clearly facilitate 
this objective. [Cognos] 

As online technologies continue to proliferate, the feasibility of providing 
web access to MCERC will undoubtedly increase. Because the Exit and Retention Census 
initiative is still in its initial stages, it remains to be seen as to whether it will be practical 
and desirable to implement web access. Nonetheless, courses of action should be 
considered in preparation for this event. 

2. Full Integration of System Components 

MCERC brings the components of a web-based survey system together without 
fully integrating them. A recommended future enhancement is the integration of the 
survey instrument database with a web-authoring capability. This enhancement would 
facilitate the publication of a survey to the web directly from the database, i.e., a new 
version of a survey would be designed with all features being recognizable in a web-based 
language. The generation of a report using this language would allow it to be published 
without having to re-enter any of the questions into the web pages and with only limited 
coding. 
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The statistical analysis aspect of the system could also be integrated with the 
survey instrument database. This integration would simplify the association of various 
versions of questions with the time-series analyses done on the variables. Co-Iocating the 
survey instrument database with the response database and relating the responses 
permanently to the instrument would facilitate having quick and understandable analyses 
of the data. 

C. CONCLUSION 

The Microsoft Access design and implementation of the MCERC database 
demonstrates the feasibility of building a system to support a complex, long term project 
like the USMC Exit and Retention Censuses. The database schema, with its version 
management capabilities, provides a way to track a dynamic, longitudinal survey 
instrument by relating responses to the survey instruments with the appropriate survey, 
and associated question versions. This combination of data and metadata in a single 
database with links to independent analytical software tools results in an integrated 
environment for supporting survey administration and analysis. 



65 



66 



APPENDIX A. MASTER FILE DATA 



NPS USMC Retention Survey. September 14, 1999 
CODEBOOK 

The following variables marked by a * will be integrated from the master file; need exact variable 
names or file locators in the master file: 



* GENPER 

*LOS 

* PUTYSTA 

* COMSOURCE 

* PMOS 

* AMOS 

*DUTYMOS 

* PAYGRADE 

* TGRADE 

* ENTRYAGE 

* AFOT 

* PERFORMRTG 



Time in active duty Service (or date entered active duty service if not available) 
Current duty station 
Commissioning source (officer only) 

Primary military occupational specialty 
Alternate MOS 



Time in current grade (or date of rank if not available) 

Entry Age (or date entered active duty service if not available) 
(enlisted only) 

“Performance measures” (These will be identified from other files) 



RESPONSE FORMATS 



Satisfaction Response Format: 

4. Very satisfied 

3. Somewhat satisfied 

2. Somewhat dissatisfied 

1. Very dissatisfied 

Agree Response Format: 

4. Strongly agree 

3. Somewhat agree 

2. Somewhat disagree 

1. Strongly disagree 

Frequency Response Format: 

5. Never 

4. Seldom 

3. Some of the time 

2. Most of the time 
1. All of the time 
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Quality Response Format: 

5. Excellent 

4. Very good 

3. Good 

2. Poor 

1. Very poor 

Probability Response Format: 

1. 0% (no chance) 

2. 10% (very 7 slight possibility) 

3. 20% (slight possibility) 

4. 30% (some possibility) 

5. 40% (fair possibility) 

6. 50% (fairly good possibility) 

7. 60% (good possibility) 

8. 70% (probable) 

9. 80% (very probable) 

10. 90% (almost sure) 

11. 100% (certain) 



USMC RETENTION CENSUS 

This survey will take approximately 30 minutes. The information in this census will remain 
confidential. It will not be used to identify 7 individuals. The results will be used only to report trends. 
Your sincere responses are needed to help improve decisions affecting Marine Corps Personnel. 

VARIABLE NAME (NPS) USMCname 

DEMOGRAPHICS 



DUNITTYP unitype 

What is the type of unit you are currently assigned to? 



1. Base/station 

2. Division/Regiment/Battalion 

3. Drill instructor/Sgt. Instructor OCS 

4. Embassy 

5. MSG 

6. HQMC/MCCDC 

7. Instructor (MOS) 

8. Joint duty 

9. Marine Barracks/MCSF 

10. Marine support battalion 

1 1 . Recruiting duty 



12. Wing/Group Squadron 

13. Reserve support 

14. FSSG/Battalion/Company 

15. Ship’s company 

16. SRIG 

17. MEU Staff 

18. Training support 

19. Long term schools/ 
Training (greater than 
6 months) 

20. Other-not listed 
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DDEPLOY deploystat 



What is your current deployment status? 

1. lm currently deployed 

2. I’m not currently deployed, but have deployed in the last 12 months 

3. Neither of the above 

DRENLST (Enlisted only) reenl_advstat 

How many times have you reenlisted in the Marine Corps? (Please do not include extensions) 

1. I have never reenlisted 

2. I have reenlisted once 

3. I have reenlisted twice 

4. 1 have reenlisted three or more times 



NOTE: Combined with DPROMO as single field with multiple entries, reenl_advstat. 
DPROMO (E5 and above only) reenl__advstat 

To the best of your knowledge, what is your current promotion/advancement status? 
NCOOFF1 I’m not yet in zone 

NCOOFF2 Pll be in primary zone for the next promotion board 

NCOOFF3 I’ve been selected for promotion 

NCOOFF4 I’ve been passed over once for promotion 

NCOOFF5 I’ve been passed over two or more times for promotion 

NOTE: Combined with DRENLST as single field with multiple entires, reenl_advstat. 

DEDUCeduc 



What is vour highest level of education? 

1. Less than high school degree 

2. HS equivalency (e.g., GED, certificate of completion) 

3. High school diploma 

4. Less than one year of college 

5. One or more years college, no degree 

6. Associate’s degree 

7. Bachelor’s degree 

8. Master’s degree 

9. Doctoral or professional degree 
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DMARITL 



marital 



What is your current marital status? 

1. Single and never married 

2. Single and divorced 

3. Legally separated 

4. Married (first marriage) 

5. Married (previously divorced or widowed) 

6. Widowed 

DDEPNS depns 

How many dependent children do you have? (Highlight your selection). 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9+ 

DSCHOOL (DDEPNS>0 only) school 

My child(ren) attend the following type(s) of schools: (check all that apply) 

1. I have no children of school age 

2. Civilian (public school) 

3. Private or parochial school 

4. DoD school (overseas DoD-operated school) 

5. DoDDES school (continental U.S. DoD-operated school) 

6. Home school 

7. College 

8. Trade school 

NOTE: Multiple entries are separated by commas. 

DMILHOU milhousing 

Do you live in military housing? 

1. Yes 
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2. No 

NOTE: Code is character. 



DRACE race 

What is your race/ethnicity? (Y ou may select more than one if you have a combined racial/ethnic 
heritage). 

1. White/Caucasian 

2. Black/ African American 

3. Asian or Pacific Islander (Filipino, Guamanian, etc.) 

4. Hispanic/Latino/Spanish descent 

5. Native American, including American Indian, Aleut, Inuit, and Eskimo 

6. Other race/ethnic group 

NOTE: Multiple entries are separated by commas. 

DRELIG religion 

What is your religious preference? 

1. No religious preference 

2. Catholic 

3. Protestant (Baptist, Methodist, Lutheran, etc.) 

4. Mormon 

5. Jewish 

6. Orthodox Christian (Greek, Russian, etc.) 

7. Muslim 

8. Buddhist 

9. Hindu 

10. Atheist 

11. Agnostic 

12. Some other religion 

DSPJOB (DMARITL=4 or 5 only) spousjob (Mark all that apply) 

What is your spouse’s employment situation? 

1. My spouse works full time in a civilian job 

2. My spouse works part time in a Chilian job 

3. My spouse is unemployed, but actively seeking employment 

4. My spouse works in the home (homemaker) 

5. My spouse works at home (self-employed) 

6. My spouse is a student 

7. My spouse is active duty military 

NOTE: Multiple entries are separated by commas. 

FAMILY ENVIRONMENT AND PERSONAL LIFE 



FSPRLOC (DMARITL=4 or 5 only) 



spoucareer 



To what extent have your spouse’s career opportunities been limited by frequency of relocation? 

1. Not at all 

2. Somewhat 

3. A great deal 

FSPDLOC (DMARITAL=4 or 5 only) spouloca 

To what extent have your spouse’s career opportunities been limited by duty location? 

1. Not at all 

2. Somewhat 

3. A great deal 

FSCHLSAT (DDEPNS>0 only) schoolsat 

How satisfied are you with the school system(s) your children use? [Satisfaction response format 
with additional response category, n/a] 

FDYCARAV (DDEPNS>0 only) daycare 

How satisfied are you with the availability of daycare in your area? [Satisfaction response format 
with additional response category, n/a] 

FDYCAROU (DDEPNS>0 only) daycaresat 

How satisfied are you with the quality of the day care you use? [Satisfaction response format 
with additional response categoiy, n/a] 

FDYCARCO (DDEPENS>0 only) daycarecost 

How satisfied are you with the cost of daycare in your area? [Satisfaction response format with 
additional response category, n/a] 

FDENTAL (DMARITL=4 or 5 and DSP JOB *6; or DDEPNS>0) dentaldepsat 

How satisfied are you with the dependent dental insurance program? [Satisfaction response 
format] 

FMEDAV (DMARITL=4 or 5 and DSPJOB *6; or DDEPNS>0) medfamavail 

How satisfied are you with the availability of FAMILY medical care? [Satisfaction response 
format] 

FMEDOU (DMARITL=4 or 5 and DSPJOB *6; or DDEPNS>0) medfamqual 

How satisfied are you with the quality of FAMILY medical care? [Satisfaction response format] 
FQTRSAT qtrssat 

How satisfied are you with your current housing? [Satisfaction response format] 
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FOTRAV 



qtrsgov 



How satisfied are you with the AVAILABILITY of government quarters? [Satisfaction response 
format] 



FQTRSAF qtrssafe 

How satisfied are you with the safety and security of your housing neighborhood? [Satisfaction 
response format] 

F AMTIME (DMARITL=4 or 5 .or DDEPNS>0) f amtime 

How satisfied are you with your balance of work and family time? [Satisfaction response format] 

FOBEN (DMARITL=4 or 5 or DDEPNS>0) ofambensat 

Ov erall, how satisfied are you with the benefits and programs for families provided by the 
Marine Corps? [Satisfaction response format] 

PAY & BENEFITS 

BPENTAL dentalsat 

How satisfied are you with YOUR dental care? [Satisfaction response format] 

BMEDAV medavail 

How' satisfied are you with the availability of YOUR medical care? [Satisfaction response 
format] 

BMEDO medqual 

How satisfied are you with the quality of YOUR medical care? [Satisfaction response format] 



BBAH bah 

How satisfied are you with the amount you receive for your Basic Housing Allowance? (BAH, 
which used to be known as VHA and B AQ, is designed to pay 80% of your housing costs) 
[Satisfaction response format] 

BBASPAY basepaysat 

How satisfied are you with the amount of your base pay? [Satisfaction response format] 
BSLPAYAV spclpavavail 
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How satisfied are you with the availability of special pays, such as bonuses or special duty 
assignment pay? [Satisfaction response format] 

BSPAYAM spclpaysat 

How satisfied are you with the amount of special pays, such as bonuses or special duty 
assignment pay? [Satisfaction response format with additional response category, 5 not 
applicable] 



BPCS pcssat 

How satisfied are you with the amount of reimbursement for PCS moves? [Satisfaction response 
format] 

BRENLTBO (Enlisted only) reelist (?) 

(Not applicable for officers) 

How satisfied are you with the amount available for re-enlistment bonuses? [Satisfaction 
response format] 

BTOTPAY milcompsat 

How satisfied are you with your total military compensation? [Satisfaction response format] 

BMWR benmwr 

How satisfied are you with MWR benefits? [Satisfaction response format] 

BEDUC benedu 

How satisfied are you with your educational benefits? [Satisfaction response format] 

BRETC benretire 

How satisfied are you with retirement benefits as outlined under current law?[Satisfaction 
response format] 



BTREND benefitsa 

Generally, my observation is that benefits are: 

1. Greatly improving 

2. Improving 
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3. Staying the same 

4. Slowly eroding 

5. Being severely cut 



BOBEN obensat 

Ov erall, how satisfied are you with YOUR benefits? [Satisfaction response format] 
BOPAYopaysat 

Ov erall, how satisfied are you with YOUR pay? [Satisfaction response format] 

JOB-RELATED QUESTIONS 

JCURR iobsat 

How satisfied are you with your current job assignment? [Satisfaction response format] 

JPMOS pmossat 

How satisfied are you with the extent to which you are assigned to jobs within your primary 
MOS? [Satisfaction response format] 

JCHAL chaljobsat 

How satisfied are you with the level of challenge in your current job? [Satisfaction response 

format] 

JHOURS workhrsat 

How satisfied are you with the number of hours you are required to work? [Satisfaction response 
format] 

JAUTH authorsat 

How satisfied are you with the authority you are given to do your job? [Satisfaction response 
format] 

JRESP responsat 

How satisfied are you with the level of responsibility in your current job? [Satisfaction response 

format] 

JEXPECT expect 

Are you doing the things you expected to be doing when you ORIGINALLY joined the Marine 

Corps? 
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1. Yes 

2. No 

0. I had no expectations regarding my job as a Marine 

JCNTRIB helpgoals 

I feel my contributions help my unit accomplish its mission 
[Agree response format] 

JUSTAFF understf 

How often have you had to “pick up the load” due to the 
unit being understaffed? 

[Frequency response format] 



jrWKFAIR workfair 

How often have you had to “pick up the load” because seniors in the chain of command don't 
assign work fairly? [Frequency response format] 

JOJOB ojobsat 

Overall, how satisfied are you with your current military job and working conditions? 
[Satisfaction response format] 



I have received the training needed to make my contribution to unit readiness. [Agree response 
format] 



TRAINING and EQUIPMENT 



TREAD Y trainready 



TNEW 



trainnew 



Recruit/initial training is fully adequate. [Agree response format] 



TMOS 



trainmos 



MOS training is fully adequate. [Agree response format] 



TOJT 



trainojt 



On-the-job-training is fully adequate. [Agree response format] 



TPME 



trainpme 



Professional Military Education is fully adequate. [Agree response format] 
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TEXER 



trainexercise 



Effective training occurs during exercises. [Agree response format] 

TCMBT traincmbt 

Combat skills training is fully adequate. [Agree response format] 

TNUNIT trainunit 

Unit-level training (not combat skills) is fully adequate. [Agree response format] 

TEQPP equipwarper 

My unit has the necessary personal equipment (782 gear, personal weapons, special clothing, 
etc.) to accomplish our mission. [Agree response format] 



TEQPU equipwarunit 

My unit has the necessary unit equipment (crew served weapons, comm gear, vehicles, aircraft, 
computers, etc.) to accomplish our mission. [Agree response format] 

TEQPNEE equipnee 

(Y ou are not required to answer this question). What equipment do you need? Please list 
representative items below. 



TOTRAIN otrainsat 

Overall, how satisfied are you with your Marine Corps training and equipment? [Satisfaction 
response format] 

TOEQP oequipsat 

Overall, how satisfied are you with your Marine Corps equipment? [Satisfaction response 
format] 



CAREER 

CASIGN assignsat 

How satisfied are you with your ability to have some influence over your assignments in the 
Marine Corps? [Satisfaction response format] 

CSECUR jobsecsat 

How satisfied are you with your job security in the Marine Corps? [Satisfaction response format] 



CADVOP advoppsat 
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How satisfied are you with your opportunities for promotion and advancement in the Marine 
Corps? [Satisfaction response format] 



CDEV careerdevsat 

How satisfied are you with your opportunities for career development (training, education) in the 
Marine Corps? [Satisfaction response format] 

CSPSUP (DMARITL=4 or 5 only) jobsatsp 

My spouse encourages me to continue my career in the Marine Corps . [Agree response format] 

IAGAIN mar again 

If I had to do it over, I’d again choose to be a United States Marine. [Agree response format] 
IRECOM marrec 

I’d recommend joining the Marine corps to a friend or relative. [Agree response format] 

CPROMO promotfair 

Promotions in the Marine Corps are based on effective performance, competence, and published 
Marine Corps standards (e.g., PME, height/weight) [Agree response format] 

CPROMOP promoprb 

“What do you think your chances are of being promoted to the next higher grade? (If you are 
planning to leave active duty Marine Corps service, please answer as though you were staying.) 
[Probability response format with additional response category, n/a, does not apply] 

COCREER ocareersat 

Overall, how satisfied are you with career opportunities in the Marine Corps? [Satisfaction 
response format] 

READINESS, W ORK ENVIRONMENT, MORALE, TEMPO 



CTMPO optempo 



For me personally, the operations tempo (i.e., number of deployments, exercises, contingencies) 
is: 

5. Much too high 
4. A little too high 
3. About right 
2. A little too low 
1. Much too low 



FAWAY timeaway 
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How much accumulated time have your Marine Corps duties required you to be away from home 
during the past year? Include all field time, other training, FMF duty and TAD that required you 
to be away from your barracks or home for periods of more than 24 hours. 

1. None at all 

2. 1 week - 3 months 

3. 4 - 6 months 

4. 7 - 9 months 

5. 9-12 months 

SOVVNUP mistakresp 

In my unit, when mistakes occur, those involved take responsibility. 

1. Never 

2. Seldom 

3. Some of the time 

4. Most of the time 

5. All of the time 

SZERQ zerodefcmd 



How often have you felt that a "zero-defect'’ standard (i.e., any mistake, however minor, could 
jeopardize your career) was applied to you or others in your unit during the last year? 

1. Never 

2. Seldom 

3. Some of the time 

4. Most of the time 

5. All of the time 

SRACE cmdreseth 

How satisfied are you with your command's response to instances of racial/ethnic discrimination? 
[Satisfaction response format with additional response category, 5, not applicable, no 
discrimination observed or experienced] 

SGENDER cmdresgndr 

How satisfied are you with your command's response to instances of gender discrimination or 
sexual harassment?[Satisfaction response format with additional response category, 5, not 
applicable, no discrimination observed or experienced] 

SRELIG cmdresrel 

How satisfied are you with your command’s response to instances of religious discrimination? 
[Satisfaction response format with additional response category, 5, not applicable, no 
discrimination observed or experienced] 
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SMORAL 



unitmotiv 



The morale in my unit is: 

5. Very high 
4. High 
3 . Moderate 
2. Low 
1. Very low 

SREADY unitready 

My unit’s level of readiness can best be described as: [Quality response format] 
SREADYT unitreadytrend 

My unit’s level of readiness is: 



1. decreasing 

2. staying the same 

3. increasing 

SPUBLIC publicsup 

Most Americans support the USMC. [Agree response format] 



LEADERSHIP 



How would you rate the quality of leadership of the following: 


LGENOF 


leadgen 


LFLDOF 


leadfield 


LJROF 


leadjr 


LWAROF 


leadwar 


LSNCO 


leadsnco 


LNCO 

[Quality response format] 


leadnco 



LGOALS commgoals 

My immediate seniors clearly communicate goals and plans for what this unit will achieve under 
their command. [Agree response format] 

LINPUT listenrec 

My immediate seniors listen to and consider my input. [Agree response format] 

LLEARN learn 

My immediate seniors develop, encourage, and facilitate learning. [Agree response format] 
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LSUBOR 



respect 



My immediate seniors show respect for subordinates. [Agree response format] 

LCOMM inform 

My immediate seniors keep people informed about issues affecting them. [Agree response format] 

LRECOG perform 

My immediate seniors recognize and reward good performance. [Agree response format] 

LFAIR fair 

My immediate seniors enforce performance standards fairly. [Agree response format] 

LXTRNG interfere 

My immediate seniors try to see that outside demands do not interfere with our scheduled 
training. [Agree response format] 

LINNOV inovate 

My immediate seniors encourage innovation. [Agree response format] 

LTECHtech 

My immediate seniors have the technical knowledge and military skills needed to be successful in 
this command. [Agree response format] 

LFOCUS unitgood 

My immediate seniors put the good of the unit above personal ambition. [Agree response format] 
LEXPECT expectperf 

My immediate seniors clearly explain what is expected in my performance. [Agree response 
format] 

LRESOU resource 

My immediate seniors try to see that we have the resources to do our jobs. [Agree response 
format] 

LSUPP support 

My immediate seniors support my career development. [Agree response format] 
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LCOHER 



cohere 



My immediate seniors encourage unit cohesiveness . [Agree response format] 

LMLEAP takelead 

My immediate seniors encourage me to take on leadership responsibilities. [Agree response 
format] 

LREADY ready 

My immediate seniors keep us focused on unit readiness. [Agree response format] 

LMODEL leadbehav 

My immediate seniors demonstrate, through personal example, high standards of behavior and 
ethics. [Agree response format] 

LOPENU opencandidunit 

My immediate seniors encourage open and candid discussion about unit problems. [Agree 
response format] 



LOPENP opencandidper 

My immediate seniors encourage open and candid discussion about personal problems. 
[Agree response format] 

LFDBK feedbacsat 

My immediate seniors give clear and timely feedback on my individual performance. 

[Agree response format] 

LREWRD bestreward 

Rewards and recognition are given to those who deserve them in my unit. 

[Agree response format] 

PLEAD oleadersat 

Overall, how satisfied are you with Marine Corps leadership? [Satisfaction response format] 

CIVILIAN EMPLOYMENT OPPORTUNITIES 



ESRCH jobsearch 

Have you actively looked for civilian employment in the past 12 months? 
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1. Yes 
0. No 



EOFFER joboffer 

In the past 12 months, have you received any civilian job offers? 

1. Yes 
0. No 

ESKILLS jobskills 

I have gained skills in the Marine Corps that are highly marketable for civilian employment. 
[Agree response format] 



EPROB probgoodjob 

If you were to leave the service now, how likely would you be to find a good civilian job? 

0, 0% (no chance) 

1. 10% (very slight possibility) 

2* 20% (slight possibility) 

3. 30% (some possibility) 

4. 40% (fair possibility) 

5. 50% (fairly good possibility) 

6. 60% (good possibility) 

7. 70% (probable) 

8. 80% (very probable) 

9. 90% (almost sure) 

10. 100% (certain) 



INTENTIONS/EXPECTATIONS 



1CREERE (enlisted only) careerintentenl 

Which of the following statements best describes your career intentions at this time? 
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L I intend to stay on active duty until retirement eligible 

2. I intend to stay on active duty beyond retirement eligibility 

3. I intend to stay on active duty, but not until retirement 

4. I’m not sure what I intend to do. 

5. I intend to leave the Marine Corps at my EAS. 

6. I’d like to stay on active duty but I’m not able to renew my contract at my EAS/ECC 

7. I’m being involuntarily separated before reaching my EAS. 

8. I’m voluntarily leaving before my EAS (early release for education, hardship discharge, etc.) 

ICREERO (officers only) careerintentofc 

Which of the following statements best describes your career intentions at this time? 

1. I intend to stay on active duty 7 until retirement eligible 

2. I intend to stay on active duty beyond retirement eligibility 

3. I intend to stay on active duty, but not until retirement 

4. I’m not sure what I intend to do. 

5. I intend to leave the Marine Corps voluntarily at the end of my current obligation. 

6. I’d like to stay on active duty but I’m not able to augment. 

7. I’m being involuntarily separated 

8. I’m voluntarily leaving before my EAS or end of current obligation (early release for 
education, hardship discharge, etc.) 



IRENLST (enlisted only ) reenlistenl (?) 

How likely are you to re-enlist at the end of your current term of service? 

1. Does not apply, I plan to retire 

2. Does not apply, I plan to leave active duty service 

[Probability response format with additional response categories] 

LAUGMNT (Officers only) augment 

How likely are you to apply for augmentation in the regular Marine Corps? [Probability response 
format with additional response category, 0, does not apply, I am already a regular officer] 

IYEARS intentyrs 

When you finally leave the Marine Corps, how many years do you expect to have served on active 
duty? 

1 11 21 

2 12 22 
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3 


13 


23 


4 


14 


24 


5 


15 


25 


6 


16 


26 


7 


17 


27 


8 


18 


28 


9 


19 


20 


10 


20 


30+ 



IINVOL involsep 

How likely are you to be involuntarily separated before you desire to leave the Marine Corps? 
[Probability response format] 

1QBLIG (officers only) curroblig 

How many months do you have left in your current obligation? 

0, indef. I have no current obligation 
1-6 

6-12 

12-24 

24+ 

ICURENL (enlisted only) currenl 

How soon will you complete your current enlistment contract or extension? 

1-6 months 
6-12 months 
12-24 months 
24+ months 

NOTE: Should not appear on officer survey. 

IRESRV reserve 

When you finally leave active duty, do you plan to join a Marine Corps reserve unit? 

6. Does not apply, I am not eligible to join 
5. Definitely yes 
4. Probably yes 
3. Don’t know/ not sure 
2. Probably no 

1. Definitely no 



OVERALL SATISFACTION 



OSATMC osatmc 

Overall, how satisfied are you with the Marine Corps? [Satisfaction response format] 

IMPORTANCE FACTORS 
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Regardless of your career plans with the Marine Corps, there are probably things that make you 
want to STAY in the Marine Corps and other things that make you want to LEAVE. Even if you plan to 
stay until retirement, there may be aspects of your career that sometimes make you consider leaving. 
Likewise, if you plan to leave the Marine Corps, there are probably things about being a Marine that you 
have enjoyed and that you would miss. The purpose of the last two sections of this survey is to identify 
BOTH of these sets of factors. 

How important are each of the following to your desire to leave the Marine Corps? 

4. very important 
3. important 
2. somewhat important 
1. not important 

Instructions: Rate each factor in the following list in terms of the extent to which it would make a 
contribution to your desire to leave active duty service in the Marine Corps. A later part of the census will 
allow you to identity the aspects of your life/career in the Marine Corps that would have a positive effect 
on your desire to stay on active duty sendee. 



Job 



LJCURR 


Current job assignment 


jobO 


LJFUTR 


Anticipated future job assignments 


jobl 


LJWKLD 


Fairness of distribution of workload 


job2 


LJPEERS 


Marines I work with currently 


job3 


LJHOURS 


Number of hours required by work 


job4 


LJRESPH 


Level of responsibility in my current job assignment: too high 


job5 


LJRESPL 


Level of responsibility in my current job assignment: too low 


job6 


LJAUTH 


Authority to do my job effectively 


job7 


LJFDBK 


Feedback on my job performance 


job8 


LJCHALH 


Work too challenging 


job9 


LJCHALL 


Work not challenging enough 


joblO 


LJTRAIN 


Availability of training to do my job effectively 


jobll 


LJEOUDP 


Availability of equipment to do my job effectively 


jobl2 


Career 






LCADVOP 


Advancement opportunities 


careerl3 


LCPROMO 


Promotion fairness 


careerl4 


LCSECUR 


Job security 


careerl5 


LCUSEMC 


Changes in the way the Marine Corps is being utilized 


careerl6 


LCDEVODDortunities for career development (training, education) 


career 17 


LMONIT 


Interaction with monitors 


careerl8 


LCPMOS 


Desirability of primary MOS 


careerl9 


LCMOSOP 


Limited career opportunities in my primary MOS 


career20 


LCXMOS 


Limited career opportunities outside my primary MOS 


careerU 


LCCIV 


Career opportunities in the civilian sector 


career22 


LCCMBAT 


Opportunity for combat training 


career23 


LCUTRNG 


Opportunities for unit level training 


career24 


LCOTRNG 


Quality of training 


career25 


LCTMPOH 


Optempo (number of contingencies, deployments, exercises): too high 


careeropta26 


LCTMPOL 


Optempo (number of contingencies, deployments, exercises): too low 


careeroptb27 
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Family Environment and Personal Life 
LFDLQCC Current duty location 

LFDLQCF Anticipated future duty location 

LFMOVEF Frequency of moves 

LFMOVES Impact of frequency of moves on spouse career 

LFLOCS Impact of duty station location on spouse’s career 

LFMOVEC Impact of frequency of moves on children’s education 

LFAWAY Time away from home/family 

LFFREE Limitations on personal freedom 

LFFSSA Availability of family support services 

Quality of family support services 



LFFSSO 

LFREC Quality of recreational services 



LFHOUAV 

LFHQUO 



Availability of housing 
Quality of housing 



Benefits 

LBRETC 

LBRETF 

LBMEDC 

LBNEDF 

LFMED 

LBPAYC 

LBPAYF 

LBEDUC 

LBINCAV 

LBINCAM 



Current retirements 

Possible changes to future retirement benefits 

Current medical/dental benefits 

Possible changes to medical/dental benefits 

Current medical/dental benefits for families 

Current pay 

Anticipated future pay 

Educational benefits 

Availability of incentive pay (e.g., bonuses) 
Adnount available of incentive pay (e.g. bonuses) 



Leadership 

LLGENOF 

LLFLDQF 

LLJROF 

LLWAROF 

LLSNCQ 

LLNCQ 

LSMORAL 

LLSUBQR 

LLTECH 

LLFQCUS 



LLCOMM 

LLINPUT 



The quality of General officer leadership 

The quality of Field grade (Maj, Lt Col, Col) leadership 

The quality of Jr. officer (Capt, Lt) leadership 

The quality of warrant officer leadership 

The quality of SNCO leadership 

The quality of NCO leadership 

Unit morale 

Immediate seniors' treatment of subordinates 
Immediate seniors’ technical competence 

Immediate seniors’ focus on personal advancement versus the good 
of the unit 

Communication to marines about issues affecting them 
Immediate seniors’ consideration of input from individual marines 



Culture 



famenvperlife28 
famenvperlife29 
famenvperlife30 
famenvperlife31 
famenvperlife32 
famenvperlife33 
famenvperlife34 
famenvperlife35 
famenvperlif e36 
famenvperlife37 
famenvperlife38 
famenvperlif e39 
famenvperlife40 



benefits41 

benefits42 

benefits43 

benefits44 

benefits44a 

benefits45 

benefits46 

benefits46a 

benefits47 

benefits48 



leadership49 

leadership50 

leadership51 

leadership52 

leadership53 

leadership54 

leadership55 

leadership56 

leadership57 

leadership58 

leadership59 

leadership60 
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LSPUBLIG 

LSFITH 

LSFITLPhysical 

LSAPPRH 

LSAPPRL 

LSMORLH 

LSMORLL 

LSZERO 

LSXTRNG 

LSRACE 

LSGENDR 

LSRELIG 



Public support for USMC 

Physical fitness standards: too high 

fitness standards: too low 

Personal appearance standards: too high 

Personal appearance standards: too low 

Moral standards: too high 

Moral standards: too low 

Zero defects standard of performance (low tolerance for mistakes) 

Outside demands that interfere with training 

Racial discrimination 

Gender discrimination 

Religious discrimination 



culture61 

culture62 

culture63 

culture64 

culture65 

culture66 

culture 67 

culture68 

culture69 

culture70 

culture71 

culture72 



Please list any other features that would contribute to your desire to leave active duty service ONLY 
IF you would rate them as ‘Very important” to your decision. 



L WRITE 1 
LWRITE2 
LWRITE3 
LWRITE4 



#1 (-9 if no response) 
#2 (-9 if no response) 
#3 (-9 if no response) 
#4 (- 9 if no response) 



writeinfl 

writeinf2 

writeinf3 

writeinf4 



[Note: construct a list of factors rated as ‘Very 7 important”; or “important” if the preceding list is a 
“null set.”] 



Instructions : Those factors that you identified as most important that would affect your decision to leave 
active duty Marine Corps are listed below. Rank order the top four that would influence you to leave: 
LRANK1 Most important factor in desire to leave rankfactorl 

LRANK2 Second most important factor in desire to leave rankfactor2 

LRANK3 Third most important factor in desire to leave rankfactor3 

LRANK4 Fourth most important in desire to leave. rankfactor4 



Note: Responses appear in the database as "‘question ” where is the number at the right edge of 

the USMC name or writeinfl - writeinf4. 



Instructions: Rate each factor in the following list in terms of the extent to which it would make a 
positive contribution to your desire to stay on active duty service in the Marine Corps. 



How important is each of the following to your desire to stay in the Marine Corps? 



4. 


Very important 




3. 


Important 




2. 


Somewhat important 




1 . 


Not important 




Job 

SJCURR 


Current job assignment 


jobm73 


SJFUTR 


Anticipated future job assignments 


jobm74 


SJPEERS 


Marines I work with currently 


jobm75 


SJRESP 


Level of responsibility I am given 


jobm76 


SJAUTH 


Authrority to do my job effectively 


jobm77 


SJFDBK 


Feedback on my job performance 


jobm78 


SJCHAL 


Challenging work 


jobm79 
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Career 



SCADVOP 


Advancement opportunities 


careerm80 


SCSECUR 


Security 


careerm81 


SCMISSN 


Participation in the mission of the Marine Corps 


careerm82 


SCDEV Opportunities for career development (training, education) 


careerm83 


SCMGMT 


Career management 


careerm84 


SCOPPMC 


Career opportunities in the Marine Corps 


careerm85 


SCPMOS 


Primary MOS job assignments 


careerm86 


SCXPMOS 


Non-primary MOS job assignments 


careerm87 


SCCMBAT 


Opportunity for combat training 


careerm88 


SCTMPO 


Optempo (number of contingencies, deployments, 
and exercises) 


careerm89 



Family Environment and Personal Life 



SFDLOCC 

SFLOCO 

SFMOVEF 

SFFSS 



Current duty location 

Opportunity to serve in other duty locations 
Frequency of moves 
Family support services 



SFREC Recreational services 



SFMHOU Access to military housing 



famenvperlifem90 

famenvperlifem91 

famenvperlifem92 

famenvperlifem93 

famenvperlifem94 

famenvperlifem95 



Benefits 

SBRET Retirement benefits 
SBMED Medical/dental benefits 

SBPAY Military pay 

SBINC Amount and availability of incentive pay (e.g., bonuses) 



benefitsm96 

bencfitsm97 

benefitsm98 

benefitsm99 



Leadership 

SLGENOF 

SLFLDOF 

SLJRQF 



The quality of General officer leadership 

The quality of Field grade (Maj, LtCol, Col) leadership 

The quality of Jr. officer (Capt, Lt) leadership 

The quality of Warrant officer leadership 

The quality of SNCO leadership 



SLWAROF 
SLSNCO 

SLNCOThe quality of NCO leadership 



leadershipmlOO 

leadershipmlOl 

leadershipml02 

leadershipml03 

leadershipml04 

leadershipml05 

leadershipml06 

leadershipml07 

leadershipm!08 



SSUNITP Unit cohesion and pride 

SLSUBOR Immediate seniors’ treatment of subordinates 

SLTECH Immediate seniors’ technical competence 

SLFOCUS Immediate seniors’ focus on the good of the unit versus personal 

advancement leadershipml09 

SLCOMM Communication to marines about issues affecting them leadershipml 10 

SLINPUT Immediate seniors’ consideration of input from individual marines leadershipml 1 1 
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Culture 



SSPUBLIC 


Public support for USMC 


culturell2 


SSFIT 


Physical fitness standards 


culture!13 


SSAPPR 


Personal appearance standards 


culture 114 


SSMORL 


Moral standards 


culturellS 


SSSERVE 


Chance to serve country 


culture!16 


SSPRIDE 


Pride in being an active duty Marine 


culture!17 


SSTRAVEL 


Opportunity to travel 


culture!18 


SSWOMEN 


Opportunities for women in the Marine Corps 


culturell9 


SSMINOR 


Opportunities for racial/ethnic group minorities in the Marine Corps culturel20 


SSFRNDS 


Friendships and acquaintances 


culturel21 



[Note: Construct a list of factors rated as ‘Very important”; or “important” if the preceding list is a 
“null set”] 



Instructions: Those factors that you identified as most important to your desire to stay on active duty 
service in the Marine Corps are listed below. Rank order the top four: 

SRANK1 Most important factor in desire to stay rankfactorml 

SRANK2 Second most important factor in desire to stay rankfactorm2 

SRANK3 Third most important factor in desire to stay rankfactorm3 

SRANK4 Fourth most important factor in desire to stay. rankfactorm4 



Note: Responses appear in the database as ‘question ” where is the number at the right edge of 

the USMC name or writeinfl - writeinf4 
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APPENDIX B. DATA DICTIONARY 



This data dictionary for the MCERC database is organized as follows: 

A. Table/Relation definitions: Provides an overview and purpose of each table in 
alphabetical order, their basic elements, and their identifying characteristics. 

B. Field definitions: Provides specific information about each field in the database, 
including data type, field length, uniqueness, indexing. Information is provided as 
a view of each field within the table definition from Microsoft Access™. The 
fields are arranged in the sequence they appear within the tables, with the tables 
arranges in alphabetical order. 

A. Table/Relation Definitions 

CHOICE_SET 

The CHOICE_SET table contains only the identifier of a set of choices and 
a description of the set. It relates to a repeating group of choices 
represented by the CHOICE_SET_Choice table. 



CHOICE_SET_Choice 

The CHOICE_SET_Choice table contains a repeating set of choices, 
representing the responses a respondent may choose from when taking a 
survey. The identifier is a composite key with the CHOICE_SET table 
identifier as a foreign key and each Choice number for a set as the unique 
key. 



QUESTION 

The QUESTION table contains only the basic elements of a question. It is 
the archetype of a version of a question. As such, it only contains the 
identifying information of questions; the description and the identifier/key. 



QUESTIONVERS 

The QUESTIONVERS table contains specific information about a version 
of a question. The archetype of QUESTIONVERS is QUESTION. Thus 
it represents related instances of an instance of QUESTION. Records in it 
are identified by the combination of the key of QUESTION as a foreign 
key, and a version numberfield. 
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RESPONDENT 

The RESPONDENT table contains information about each respondent 
who takes a survey. The unique identifier is the Social Security Number 
(SSN) of the respondent. Other information includes demographics and 
personal information. 



RESPONSE 

The RESPONSE table contains information about each response a 
respondent makes. The unique identifier for each record is composed of 
foreign keys from the RESPONDENT, SURVEYVERS, and 
QUESTIONVERS tables, plus the Datestamp field. The only other 
information in this table is the choice the respondent provides in response 
to a particular question on a particular survey on a particular date. 

SURVEY 

The SURVEY table contains only the basic elements of a survey. It is the 
archetype of a version of a survey. As such, it only contains the identifying 
information of surveys; the description and the identifier/key. 



SURVEYVERS 

The SURVEYVERS table contains specific information about a version of 
a survey. The archetype of SURVEYVERS is SURVEY. Thus it 
represents related instances of an instance of SURVEY. Records in it are 
identified by the combination of the key of SURVEY as a foreign key, and 
a version numberfield. 



SURVEYVERS_QUESTIONVERS_X 

The SURVEYVERS_QUESTIONVERS_X table is the junction table that 
results from the many-to-many relationship between SURVEYVERS and 
QUESTIONVERS. As such, it contains foreign keys from 
SURVEYVERS and QUESTIONVERS. In addition, it contains fields 
unique to the union of the two tables. 
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Field Definitions/ by table 




CHOICE SET.ChoiceSetID 




CHOICE_SET.ChoiceSetDescription 
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CHOICE SET Choice. ChoiceSetED FK 




CHOICE SET Choice. ChoiceNumber 
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CHOICE_SET_Choice.ChoiceDescription 




CHOICE SET Choice. ID 
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QUESTION. QuestionName 




QUESTION. Description 
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QUESTIONVERS . Question 




QUESTIONVERS . QDetail 
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QUESTIONVERS.Format 




QUESTIONVERS.ED 
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QUESTIONVERS.ChoiceSetID_FK 




RESPONDENT. SSN 
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RESPONDENT.Name 




RESPONDENT. Demographics_Gender 
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RESPONDENT. Deraographics_Birthdate 
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RESPONSE. SSN_FK 




RESPONSE. SURVEYVERS ID FK 
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RESPONSE. QUESTIONVERS_ID_FK 




RESPONSE.DateStamp 
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RESPONSE. Choice 




SURVEY. SurveyName 
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SURVEY. Description 




SURVEYVERS. Survey VersionEDjSurveyNameJFK 
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APPENDIX C. APPLICATION CODE 



This appendix contains the application code for the data conversion program of MCERC. 

The code is written using Visual Basic, version 6.0. It converts data from the 4 column 
table format of a MS Access™ table received from the response database, to the response 
matrix format required for a statistic; 1 .! analysis application. It allows saving the reponse 
matrix in either MSExcel™ or a comma-delimited ASCII text file. 



CODE: 



Private Sub cmdClose_Click ( ) 

End Sub 

Private Sub ASCII_Click ( ) 

If ASCI I. Value = True Then 
Excel. Value = False 

Label 3 .Caption = "Saving Data to ASCII ’rile" 

End If 
End Sub 

Private Sub CommandButton2_Click{ ) 

'excel sheets have a 255 column 
'maximum so we have to span 
'multiple sheets these one 
'dimension arrays are used 
'to speed the transfer to excel 



Public Matrixl(0 To 1000, 0 To 205) String 
Dim Matrix2(0 To 1000, 0 To 10C) As String 
Dim singleRowl(0 To 205) As String 
Dim singleRow2(0 To 100) As String 



Dim BigMatrix(0 To 1000, 0 To 3 1 T - . String 'Used for ASCII format 

Dim textOut As String 'used to speed file transfer 



Dim xlApp As Object 
Dim spreadsheetColumn As Integer 
Dim spreadsheetRow As Integer 
Dim count As Long 
Dim i As Integer 
Dim n As Integer 



Processed = True 



ProgressBarl .Max = datQuestRS. Recordset . SacordCount - 1 
For n = 0 To da tQuestRS. Recordset .RecordC our. t - I 
MSHFlexGrid2 . Row = n + 1 



If n <= 203 Then 

Matrixl(0, n + 2) = MSHFlexGrid2 . 1 ext 
Else: Matrix2(0, n + 2 - 204) = MSHFIcxGr id2 . Text 
End If 



ProgressBarl .Value = n 



' label the columns 



i i 1 



Next n 



ProgressBarl .Max = da tRespRS .Recordset . RecordCount 'label the rows 

For n = 0 To da tRespRS .Recordset . RecordCo -nt - 1 

MSHFlexGrid3 .Row = n + 1 
MSHFlexGrid3 .Col = 0 

Matrixl(n + 1, 0) = MSHFlexGrid3 . Text 
Matrix2(n +1, 0} = MSHFlexGrid3 . Text 
MSHFlexGrid3 .Col = 1 

Matrixl (n + 1, 1) = MSHFlexGrid3 . Tex:: 

Matrix2(n +1, 1) = MSHFlexGrid3 . Text 
ProgressBarl .Value = n 

Next n 



Matrixl (0, 


0) 


= "Last 4 of ssn" 


Matrix2 (0, 


0) 


= "Last 4 of ssn" 


Matrixl (0, 


1) 


= "date /time" 


Matrix2 (0, 


1) 


= "date /time" 



' populate matrix with data 



MatrixColumn = 0 
MatrixRow = 0 
count = 1 

ProgressBar2 .Max = datPrimaryRS . Meco: oset . RecordCount 
datPrimaryRS .Recordset .MoveFirst 

Do While count <= datPrimaryRS . Recordset .RecordCount 
ProgressBar2 .Value = count 

If ( datPrimaryRS. Recordset .Fields ( 3} .Value = Matrixl (MatrixRow, 0) _ 

Or datPrimaryRS .Recordset .Fields (3 ; .Value = Matrix2 (MatrixRow, 0)) Then 

' do the ssn's match? 

Do While MatrixColumn < 206 

If (datPrimaryRS .Recordset . Fields (2 .Value = Matrixl(0, MatrixColumn)) Then 

' do the questions match? 

Matrixl (MatrixRow, MatrixColumn . = da tPrimaryRS .Recordset . Fields (1) .Value 
count = count + 1 ' and increment the count 

da tPrimaryRS. Recordset .Mo veNe>v ' (get next question) 

End If 

MatrixColumn = MatrixColumn - 1 'move to next column in Matrix 

Loop 

Do While (MatrixColumn >= 206* Ar.c MatrixColumn < da tQuestRS. Recordset. RecordCount 

If (datPrimaryRS .Recordset . F: - Ics .Value = Matrix2(0, MatrixColumn - 206)) Then 

' do the questions match? 

MSHFlexGridl . Col =1 'if so, set the cell with answer 

Matrix2 (MatrixRow, Matr.Mol.: 206) = datPrimaryRS .Recordset . Fields ( 1) .Value 

count = count + 1 'and increment the count 

End If ' (get next question) 

MatrixColumn = MatrixColumn - I 'move to next column in Matrix 

Loop 

If MatrixColumn = datQuestRS. Record :-et. RecordCount - 1 Then 
MatrixColumn = 0 
count = count + 1 
datPrimaryRS . Recordset . MoveNcxt 
End If 



' if the ssn's don't match 
' go to the next row 
' in spreadsheet 

Loop 



Else: MatrixRow = MatrixRow - 
End If 



transfer data to excel 



If Excel. Value = True Then 

Set xlApp = CreateObject { " Exc . . Ap" . -cacion" ) 

xlApp .Visible = True 

Set xlbook = xlApp .Workbooks .Ada 

Set xlSheetl = xlbook. Worksheets \ "Sheetl" ) 

Set xlSheet2 = xlbook. Worksheet s ( ' , Pneet2" ) 

ProgressBar3 .Max = datRespRS .Recordset . RecordCount - 1 

For n = 0 To datRespRS . Recordset . Rec rdCount - 1 
For i = 0 To 205 

singleRowl { i) = Matrixl r , 

Next i 

For i = 0 To 100 

singleRow2 ( i ) = Matrix2 (r.. 

Next i 

xlApp. Sheets {" sheet 1" ) -Range {xlAp: .C 's(n + 1, 1). Address, _ 

xlApp. Cells (n + 1, UBound { si; ;g 2 eKc<<* . ) ) .Address) .Value = singleRowl 

xlApp. Sheets { "sheet2" ) .Range (xlApp. Ccl_s (n 1, 1). Address, _ 

xlApp . Cells {n + 1, UBound (sing: eR)-;2 )) .Address) .Value = singleRow2 

ProgressBar3 .Value = n 

Next n 
End If 

transfer data to ASCII File 



If ASCI I. Value = True Then 

Dim fso, txtfile 

Set fso = CreateObject ( "Script ing . - Sys temObject " ) 

Set txtfile = f so . CreateTextFil ( " _ : '.ajSmith\testfile.txt", Tarue) 

ProgressBar3 .Max = da tRespRS .Recordset . Pec ordCount - 1 

For n = 0 To da tRespRS .Recordset .Reco v nCount - 1 

For i = 0 To 205 'to optimize, make output line 

txtOut = Matrixl (n, i i - 'length as close to 255 characters 

txtfile. Write (txtOut) 'as possible 

Next i 

For i = 3 To datQuestRS .Recordse* RecordCount - 204 'skip first three lines 
txtOut = Matrix2(n, i) - •• , 
txtfile .Write (txtOut) 

Next i 

txtfile .WriteLine (Matrix.' n, i 1)) 'last line in row gets 

'a newline character 
'vice a comma 

ProgressBar3 .Value = n 

Next n 

txtfile . Close 
End If 



End Sub 



Private Sub Excel_Click ( ) 



If Excel. Value = True Then 
ASCII. Value = False 

Label3 .Caption = "Saving Data to Exce . 
End If 

End Sub 



Private Sub Form_Load ( ) 

Me. Left = GetSetting (App. Title, "Se: 
Me. Top = GetSetting (App .Title, "S^t- 
Me. Width = 11000 
Me. Height = 8000 

da tPrimaryRS. Visible = False 

With MSHFlexGridl 

.Redraw = False 

. ColWidth ( 0) = -1 
. ColWidth(l) = -1 
.ColWidth (2) = -1 
.ColWidth (3) = -1 

.AllowBigSelection = True 
.FillStyle = f lexFil IRepeat, 

. Row = 0 
.Col = 0 

.RowSel = .FixedRows - 1 
.ColSel = .Cols - 1 
.CellFontBold = True 

.AllowBigSelection = False 
.FillStyle = f lexFillSingle 
.Redraw = True 

End With 

da tQuestRS. Visible = False 
With MSHFlexGrid2 

.Redraw = False 
. ColWidth(O) = 1500 



s” , "MainLeft", 1000) 
"MainTop" , 1000) 



' set grid's column widths 



' set grid's style 



' make header bold 



' set grid's column widths 



' set grid's style 

.AllowBigSelection = True 
.FillStyle = f lexFillRepea:. 



' make header bold 

.Row = 0 
.Col = 0 

.RowSel = .FixedRows - 1 
.ColSel = .Cols - 1 
.CellFontBold = True 

.AllowBigSelection = False 
.FillStyle = f lexFillSingle 
.Redraw = True 

End With 

da tRespRS .Visible = False 

With MSHFlexGrid3 

.Redraw = False 

' set grid's column widths 

. ColWidth ( 0 ) = 600 
. ColWidth ( 1) = 1100 
.Width = 2000 



' sec grid's style 

.AllowBigSelection = True 
.FillStyle = f lexFillRepea 

' make header bold 

. Row = 0 
.Col = 0 

.RowSel = .FixedRows - 1 
.ColSel = .Cols - 1 
.CellFontBold = True 

.AllowBigSelection = False 
.FillStyle = f lexFillSingle 
.Redraw - True 

End With 
End Sub 

Private Sub Form_Un load (Cancel As :r.it< 

Dim i As Integer 

'close all sub forms 

For i = Forms. count - 1 To 1 Step 1 
Unload Forms (i) 

Next 

If Me. Windows tate <> vbMinimizec T;.e.\ 

SaveSetting App. Title, "Settings". MainLeft", Me. Left 
SaveSetting App. Title, "Settings . MainTop" , Me. Top 
SaveSetting App. Title, "Settings "MainWidth", Me. Width 
SaveSetting App. Title, "Settings' "MainHeight" , Me. Height 
End If 
End Sub 

Private Sub tbToolBar_ButtonClicx on As MSComCtlLib. Button) 

On Error Resume Next 

Select Case Button. Key 

Case "New" 

'ToDo: Add 'New' button code. 



MsgBox "Add 'New' button 
Case "Open" 



'ToDo: Add 'Open' button code. 



MsgBox "Add 'Open' button code. 
Case "Save" 



'ToDo: Add 'Save' button code. 



MsgBox "Add 'Save' button code." 

Case "Print" 

'ToDo: Add 'Print' button code 

MsgBox "Add 'Print' butter, c 
Case "Cut" 

'ToDo: Add 'Cut' button code. 

MsgBox "Add 'Cut' button coc- 
Case "Copy" 

'ToDo: Add 'Copy' button code. 

MsgBox "Add 'Copy' butt< n - 
Case "Paste" 

'ToDo: Add 'Paste' button code 

MsgBox "Add 'Paste' bur 
Case "Bold" 



MsgBox "Add 'Bold' butter, cor* 



'ToDo: Add 'Bold' button code. 



Case "Italic" 


'ToDo: Add 'Italic' button code. 


MsgBox "Add 'Italic' butte: 


0 . •• 


Case "Underline" 


'ToDo: Add 'Underline' button code. 


MsgBox "Add 'Underline' e.r: 


•rode . " 


Case "Align Left" 


'ToDo: Add 'Align Left' button code. 


MsgBox "Add 'Align Lef ^ 


code . " 


Case "Center" 

MsgBox "Add 'Center' button code." 


'ToDo: Add 'Center' button code. 


Case "Align Right" 


'ToDo: Add 'Align Right' button code 


MsgBox "Add 'Align Right 
End Select 
End Sub 

Private Sub Sheetl_GotFocus ( ) 

End Sub 

Private Sub save_Click() 


o:i code . " 



transfer data to excel 



If Excel. Value = True And Processed 


l:en 


Set xlApp = CreateObject ( "Exce. . Ap: 
xlApp .Visible = True 
Set xlbook = xlApp. Workbooks .Ado 
Set xlSheetl = xlbook. Worksheets M s 


:ation" } 


Set xlSheet2 = xlbook. Worksheets 'V 




ProgressBar3 .Max = datRespRS . Records- 


. RecordCount - 1 


For n = 0 To datRespRS.Recordse .Re.ee 

For i = 0 To 205 

singleRowl (i) = Matrix, n . i 
Next i 

For i = 0 To 100 

singleRow2 (i) - Matrix.! (u, : 
Next i 


recount - 1 


xlApp . Sheets ( " sheetl" ) . Range (xlApp . O 
xlApp. Cells (n + 1, UBound(sir.oleFo 


_t(n + 1, 1) .Address, _ 

. Address) .Value = singleRowl 



xlApp . Sheets (" sheet2 "). Range (xlApp . Ce: .Is vn ^ I, 1). Address, _ 

xlApp . Cells (n + 1, UBound(sincrleRcv.v >) .Address) .Value = singleRow2 



ProgressBar3 .Value = n 



transfer data to ASCII File 



If ASCII. Value = True And Processed - ,'r Then 
Dim fso, txtfile 

Set fso = CreateObject ( " Scripting . ?_ -eSystemObject " ) 

Set txtfile = f so . CreateTextFile "C: Documents\testfile.txt", True) 

ProgressBar3 .Max = datRespRS . Recordset . F . c- recount - 1 
For n = 0 To datRespRS .Records- t . Reccru Count - 1 



For i = 3 To datQuestRS.Rec dsu ecordCount - 204 'skip first three lines 
txtOut = Matrix2 (n, i) ' 

txtfile .Write (txtOut ' 

Next i 



For i = 0 To 205 

txtOut = Matrixl(n, i) 
txtfile. Write (txtOut' 
Next i 



'to optimize, make output line 
'length as close to 255 characters 
'as possible 



txtfile. WriteLine (Matrix 



'last line in row gets 
'a newline character 
'vice a comma 



ProgressBar3 .Value = n 



Next n 



txtfile . Close 



End If 



End Sub 
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APPENDIX D. MCERC USER’S MANUAL 



Getting Started 

Please read this manual carefully before attempting to use this application. 

The MCERC application has been specifically tailored for Survey Management of 
the Marine Corps Exit and Retention Censuses (MCERC) using Microsoft Access™ for 
the survey instrument database and Cognos Powerplay™ for analysis of survey response 
data. This manual provides installation procedures to get started with MCERC, use the 
MCERC survey instrument database, and convert response data into an appropriate 
format for analysis in Powerplay. Comprehensive procedures for using Powerplay are 
available as an integrated help function when using Powerplay. 

Menu-driven selections are available to perform queries, data entry, or generate 
reports. Menu selections in this manual are in boldface while menu selections for 
Microsoft Access™ and Windows are boldface italics (the first letter may be underlined). 
Filenames are underlined. 

Installation Procedures 

1 . Place the MCERC disk in drive A:\ 

2. Copy the files MCERC.exe and MCERC.mdb . to the folder named “My 
Documents” in the C:\ drive. 

3. Follow installation procedures that come with the CD for Cognos Powerplay, 
ensuring the program files are installed in the 

C:\Program Files\Cognos\PowerPlay 6.5 directory. Select all components. 

Using MCERC 

1 . Select Start, Programs , Microsoft Access. 

2. Click File, Open. 

3. Select the file named MCERC.exe and click Open. 

4. The main menu will automatically appear. 

5. From here you can: 

a) go to the database to enter survey instrument data, conduct a query, or 

view and/or print survey codebooks. NOTE: See the Menu Selections section for a 

detailed explanation of each menu selection. 

b) go to Cognos Powerplay for analyzing data (already formatted for analysis) 
or to Cognos Transformer to build a Powercube (format data for Powerplay analysis) 
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c) transform a data set into a matrix which can then be formatted by Transformer 
for Powerplay. 



Survey Database functions 

1 . Select Manage Surveys from the Main Menu. This leads to a menu screen with the 
choices Make New Surveys and Versions, View/Print Survey Instrument 
Information, Analyze Survey Data, and Exit MCERC. Help Procedures for Access are 
available by selecting Help , Contents and Index from the main toolbar or the Help icon (a 
“?” inside a box) and entering the subject or topic on which you need help. 

>New Surveys 

To place a new survey or a new version of a survey into MCERC, select Make 
New Surveys and Versions. This leads to a menu with the options to Create a New 
Version of an Existing Survey, Create the first Version of a New Survey, Return to 
the Main Menu, or Exit MCERC. 

To place a new survey into MCERC, select Create the first Version of a New 
Survey. This leads to a survey data entry form. On this form, enter the Survey Name 
where indicated. This will automatically be designated as Version "1" for this survey 
name. It is highly recommended that a short description of the general purpose and 
intentions of this survey be entered. When entering future versions, this description will 
still apply, but there is a version description that allows you to briefly describe the 
reason/logic behind the version. The name of the person responsible for the survey, or a 
survey developer responsible for the design of the survey should be entered in the 
"Manager" block. 

Before a survey can exist, there must be a question associated with it. If MCERC 
already has a question that you want on this survey, you may choose it from the list. The 
sequence for the question may be chosen here, but as more questions are added, re- 
sequencing them may be done. The default value for sequence is 10. It is recommended 
that sequence values are given in multiples of 10, giving the possibility to easily insert 
other questions later (before the survey is fielded!) without having to re- sequence all of 
them again. Giving the inserted question a sequence value between the sequence values of 
two other questions does this. 

If the question is conditional, i.e., dependent upon another question or 
demographic factor of the respondent, you may state the condition. For example, if only 
married respondents should answer a question, you may enter "Married Only" or some 
other phrase to describe the condition. 

If MCERC does not have a question already for this survey, you may create one by 
selecting the "Create New Question" button. The procedure for entering a new question 
will be described later. Once the new question is created, you will be returned to the New 
Survey form. Click in the list of questions or the scroll bar and find the question you just 
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created. It will be in alphabetical sequence within the list. Select the question, assign it a 
sequence, and if applicable, a condition. 

If MCERC has a question for this survey, but you want to modify the question, 
select "Make a new Version of an Existing Question". Then choose from the list the 
question you want to modify. It will automatically become the next consecutive version 
number for that question. The rest of the procedure for modifying a question will be 
described later. Once you have made the modifications (i.e., made a new question 
version), you will be returned to the New Survey form. Click in the list of questions or the 
scroll bar and find the question you just created. It will be in alphabetical sequence within 
the list. Select the question, assign it a sequence, and if applicable, a condition. 

>New VERSIONS of Surveys 

To place a new version of a survey into MCERC, again select Make New Surveys 
and Versions. Then choose Create a New Version of an Existing Survey. This leads 
to a data entry form for the next version of a survey. Select the survey from the list that 
you desire to make another version for. This automatically sets the next consecutive 
version number. It will display the survey description for that survey that was entered the 
first time a survey by that name, with that purpose was entered. It is highly recommended 
that a brief description of the version, i.e., a memorandum noting the general differences 
be entered in the version description field. The name of the person responsible for this 
version of survey, or a survey developer responsible for the design of the version should 
be entered in the "Manager" block. 

Before a version of a survey can exist, there must be a question associated with it. Refer 
to the New Survey procedures above, as the procedures for placing questions on a new 
version are identical to placing questions on a new survey. 

>New Questions for New Surveys or Versions of Surveys 

To design a new question for a new survey or survey version, select the Create 
New Question command button from the form as described under the New Survey 
section. Enter the question name (automatically version 1), and the description of the 
question to document the information you are attempting to collect with this variable. 
Then enter the actual question, followed by the format (single, multiple, write-in, etc.). 
Then select a choice set from the drop box. If you want to make a new choice set, select 
the New Choice Set button. This allows you to name a new Choice Set, describe it, and 
define as many choices as you want for respondents to choose from. You must sequence 
the choices as you want them to appear. When the Choices are all entered for a Choice 
Set, close the form by clicking on the "x" in the upper right comer. This takes you back to 
the form for making a new question. Select the Choice Set name you just defined. Then 
press enter (keyboard) to clear the question form. Click the "x" in the upper comer of this 
form. This takes you back to the survey form. Select from the list the Question you just 
created. Assign a sequence and a condition (if needed). Press enter to update the database 
and clear the form. 
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Note: When defining Choices, you may enter any number you like for the 
ChoiceNumber. They can be in reverse sequence if desired, and "0" may be used. 
However, you must enter the "0" even though it appears in the field already. Ensure you 
do not repeat numbers, and give them sequence numbers for the order in which you want 
them to appear to the respondent. (If you want the first question to have the highest value 
of 5 choices, give value 5 a sequence of 1, 4 a sequence of 2, etc.) 

>Modify Questions for New Surveys or Versions 

To modify a question is to make a new version of it. The procedure is very similar 
to making a new question, except you must select the question you wish to modify. When 
you select it from the list, your new question is automatically assigned the next 
consecutive version number. You then assign the format, type in the question, and assign 
a choice set in the same manner as described in the "New Questions for New Surveys or 
Versions of Surveys" section above. A description of this version, i.e., a short justification 
of the change, is highly recommended. 

>Add Questions to a Survey (before it is fielded!) 

To add questions to a survey, select Add Questions to Working Copy of 
Survey. From there you can select questions in the list one at a time, click on the survey 
you are placing them on, assign a sequence, and a condition. 

>View/Print Survey Instrument Information 

To View or Print a copy of a codebook for a survey, select View/Print Survey 
Instrument Information from the menu. A parameter box will prompt you for the 
survey name, and then the version number, so you must know this information. Once 
entered, the codebook report will be generated on the screen. To print it, simply select the 
printer icon on the toolbar, or select File , Print. 

To View or Print a listing of all available Choice Sets in MCERC, Select 
View/Print Choice Set Listing from the menu. 

Data Analysis functions 

2. From the Main Menu, there are 3 choices related to Data Analysis. The data received 
for MCERC must be manipulated into an appropriate matrix before analysis of the 
responses can be done. Once this is done, the Cognos Powerplay analysis software can be 
used to model and anlyze the data. 

>Converting Data into a Response Matrix 

To convert response data into a response matrix, you must first ensure the 
response data file you receive is located in the C:\Windows\Temp\ directory and the file is 
appropriately named Responses.mdb (Microsoft Access file). This file will consist of four 
fields (SSN, DateTaken, QuestionName, and QuestionAns) containing the last four digits 
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of the social security number, the date/time the survey was taken, the question identifier, 
and the response choice (answer) to the question for every response to every question of 
the dataset covered by the file. 

Select the Create Response Matrix button from the Main menu. This leads to a 
screen for converting the data. It may take a few minutes for this screen to appear 
because the program must read every record of the data file first. To create the matrix, 
press the Process button. This will take several minutes as the program sifts through the 
data file and arranges the data into a matrix. 

The program saves the matrix either to a text based, comma-delimited file named 
testfile.txt or to a Microsoft Excel file which you may save to a name and location of your 
choice. After the program has converted the data, you will choose the format you desire 
by clicking the appropriate. button (ASCII or Excel) and pressing Save. Once saved, this 
file may be used by Cognos Powerplay, or may be imported into another statistical 
analysis application such as SAS™ or SPSS™. Close the data conversion program by 
selecting the "x" in the top right corner. 

>Open Powerplay Transformer to build a Powercube 

To open Powerplay Transformer, you may select it from the main menu. Use the 
parameters you desire to analyze to create a Powercube design, and follow instructions 
found in the Help menu. Once you have created a Powercube, you can go straight to 
Powerplay from Transformer to analyze the cube you just made. There is an alternate 
method to open Transformer from the MCERC database screens. 

>Open Powerplay to Analyze an existing Powercube. 

To go straight to Powerplay, select it from the main menu. You may also select it 
from the MCERC database screen by selecting Analyze Survey Data. You may want to 
go straight to Powerplay when you have any Powercubes already built and desire to use 
them to create more Powerplay reports. Use the Help menu of Powerplay to guide you in 
its use. 

Backup and Recovery Procedures 

It is highly recommended that a backup disk be maintained to preserve all data 
entered in MCERC. To smoothly accomplish a backup procedure, it is recommended you 
use a ZIP disk or other external storage device. Copy the MCERC.mdb file to it 
frequently when entering data. 

To restore MCERC in the event of data loss or corruption, simply copy to files 
back from your external storage to the directory where you originally installed MCERC. 
Providing proper Backups have been performed, data loss will be kept to a minimum. 
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